Sms 2700 Intro XXXX Ud10

Telepath SMSC Release 2700
Introduction Guide
Telepath SMSC Introduction Guide
Copyright© Logica Mobile Networks Limited, 1996-2003. All rights reserved. The copyright in
this document is owned by Logica Mobile Networks Limited (“LogicaCMG”). This document
may not be reproduced, in whole or in part, in any form without the express consent of
LogicaCMG in writing.
Information contained in this document is proprietary and confidential to LogicaCMG. That

information, irrespective of form, must not be used other than for the purposes for which it is
disclosed to the recipient and must not under any circumstances be disclosed to any third party
without the express consent in writing of LogicaCMG.
Certain Trade Marks referred to in this document are the property of LogicaCMG, the rights of
owners of other Trade Marks referred to in this document are hereby acknowledged.
Although LogicaCMG uses all reasonable effort to ensure the accuracy and completeness of
this document, no warranty or representation whatever is given by LogicaCMG in respect of it
and any use of or reliance on any of the information contained herein is entirely at the risk of
the person so acting. LogicaCMG shall have no liability whatsoever in respect of any use of or
reliance on any such information.
This document corresponds to the Telepath SMSC Product for Release 2700, and also to any
subsequent release, unless otherwise indicated in technical notes or new documentation.
Logica Mobile Networks Limited,

5 Custom House Plaza
Harbourmaster Place
Dublin 1
Ireland
Confidential and Copyright © LogicaCMG. 1996-2003

Telepath SMSC Introduction Guide Table of Contents
Table of Contents
Preface ......................................................................................................................................ix
Intended Readers ................................................................................................................ x
Structure of this Document................................................................................................. x
Related Documentation .....................................................................................................xi
Typographic Conventions ................................................................................................xii
LogicaCMG Documentation ...........................................................................................xiii
1. Context of Telepath SMSC ...........................................................................................1-1
1.1 Overview of Telepath SMSC.......................................................................1-2
1.2 Telepath SMSC Local Environment............................................................1-4
1.2.1 Hardware Configuration ..............................................................................1-4
1.2.2 Proprietary Software ....................................................................................1-5
1.2.3 Telepath SMSC Software ............................................................................1-6
1.3 *Customer Care Server................................................................................1-8
1.4 Application Interfaces..................................................................................1-9
1.4.1 Mobile Network Interface............................................................................1-9
1.4.2 Short Message Peer-to-Peer Interface (SMPP)..........................................1-10
1.4.3 Network Management System Interface (NMS) .......................................1-10
1.4.4 System Manager Terminal (TPSMT) ........................................................1-11
1.4.5 Distributed and Remote Administration and Provisioning........................1-11
1.4.6 Customer Message Entry System (TPCUST)............................................1-11
1.4.7 Telocator Alphanumeric Protocol Interface (TAP) ...................................1-11
1.4.8 Telocator Network Paging Protocol (TNPP) .............................................1-12
1.4.9 Universal Computer Protocol (UCP).........................................................1-12
1.4.10 Sierra Interface...........................................................................................1-13
1.4.11 Distributed Management Metrics Module (DMM) ...................................1-13
1.4.12 * Prepaid Gateway (tpprepaidg) ................................................................1-14
1.5 Telepath SMSC External Environment .....................................................1-14
1.5.1 Short Message Entities ..............................................................................1-14
2. Message Management ...................................................................................................2-1
2.1 Short Messaging Modes ..............................................................................2-2
2.2 Classic Messaging .......................................................................................2-3
2.3 Premium Messaging ....................................................................................2-4
2.3.1 Premium Message Operations .....................................................................2-5
2.4 *Customer Care for Premium Messaging....................................................2-6
2.5 Express Messaging ......................................................................................2-7
2.5.1 Express Message Queues.............................................................................2-7
2.5.2 Express Message Retry................................................................................2-8
2.5.3 SMS Alert Notification on Express Messages.............................................2-9
2.6 *Real Time Billing ....................................................................................2-10
2.6.1 Starting Real Time Billing.........................................................................2-11
2.6.2 Stopping Real Time Billing .......................................................................2-12
2.7 Message Types...........................................................................................2-12
2.8 Short Message States .................................................................................2-13
2.9 Message Lengths .......................................................................................2-14
2.10 Short Message Responses..........................................................................2-14
SMS-2700-INTRO-xxxx-UD10 iii
Table of Contents Telepath SMSC Introduction Guide
2.11 Predefined Messages .................................................................................2-14

2.12 Registered Messages..................................................................................2-14
2.12.1 Registering Messages Submitted from TPSMT ........................................2-14
2.12.2 Mobile Originated Registered Messages ...................................................2-15
2.13 Message Completion .................................................................................2-15
2.13.1 Mode of Operation.....................................................................................2-15
3. Message Validation and Routing .................................................................................3-1
3.1 Routing Management...................................................................................3-2
3.1.1 Source Address Validation ..........................................................................3-2
3.1.2 Destination Address Validation ...................................................................3-3
3.1.2.1 Message Routing File ..................................................................................3-3
3.2 Address Translation .....................................................................................3-5
3.3 * Prepaid Validation ....................................................................................3-6
3.3.1 Successful Delivery .....................................................................................3-6
3.3.2 Unsuccessful Delivery .................................................................................3-8
3.3.2.1 Credit Unavailable .......................................................................................3-8
3.3.3 Service Unavailable .....................................................................................3-9
3.3.4 Notification that Subscriber has been Overcharged ..................................3-12
3.4 Scheduled Prepaid Messages .....................................................................3-13
3.5 Retry Mechanism.......................................................................................3-14
3.5.1 Retry Profiles .............................................................................................3-16
3.5.2 Retry Schemes ...........................................................................................3-17
3.5.3 Default Retry Profiles ................................................................................3-17
3.5.4 Message Waiting Data Override................................................................3-18
3.6 Global Title Addressing.............................................................................3-19
3.7 Home-Location Timezone .........................................................................3-19
3.8 MCE Notification ......................................................................................3-19
3.9 MSC Address Storage................................................................................3-20
3.10 Message Delivery to Dual Mode Phones...................................................3-22
3.11 Multi-Recipient Messages .........................................................................3-24
3.11.1 Maximum Number of Multi-Recipients ....................................................3-24
3.11.2 Trigger Detection Point (TDP) ..................................................................3-24
3.12 Delivery Mechanism Controls...................................................................3-25
3.12.1 Message Delivery Triggers........................................................................3-25
3.12.2 Mobile Registration Delay.........................................................................3-25
4. Provisioning Customers ................................................................................................4-1
4.1 Provisioning.................................................................................................4-2
4.2 Customer Validation ....................................................................................4-2
4.2.1 Validation Process .......................................................................................4-3
4.2.2 Extended Device Addressing.......................................................................4-4
4.3 Distribution Lists .........................................................................................4-5
4.4 Service Access Control................................................................................4-5
4.5 User Groups .................................................................................................4-5
4.5.1 Messaging Resources...................................................................................4-5
4.5.1.1 Message Operation Processing ....................................................................4-6
4.5.1.2 Storage Capacity ..........................................................................................4-6
4.5.2 Allocation ....................................................................................................4-6
4.5.3 Throttling .....................................................................................................4-7
4.5.3.1 MOP Throttle...............................................................................................4-7
iv SMS-2700-INTRO-xxxx-UD10
Telepath SMSC Introduction Guide Table of Contents
4.5.3.2 Storage Throttle ...........................................................................................4-7

4.5.4 User Group Retry.........................................................................................4-8
4.6 Closed User Groups (CUGs) .......................................................................4-8
5. Platform Management ..................................................................................................5-1
5.1 Capacity Licence Monitor ...........................................................................5-2
5.2 Network Cluster Member Formats ..............................................................5-3
5.3 Network Specific Address Formats Definitions ..........................................5-4
5.4 Network Error Code Definitions .................................................................5-5
6. Billing Customers ..........................................................................................................6-1
6.1 Telepath SMSC Billing................................................................................6-2
6.2 Billing Processes..........................................................................................6-3
6.3 Billing File Formats.....................................................................................6-5
6.4 * Pre-Paid Billing ........................................................................................6-5
6.5 File Naming Convention..............................................................................6-5
6.6 *Real Time Billing ......................................................................................6-5
7. Monitoring the System ..................................................................................................7-1
7.1 Monitoring the System ................................................................................7-2
7.2 Monitoring Telepath SMSC Processes ........................................................7-3
7.3 Monitoring the UNIX System .....................................................................7-4
8. Event and Alarm Management ....................................................................................8-1
8.1 Events ..........................................................................................................8-2
8.2 Event Types .................................................................................................8-3
8.3 Event Filtering .............................................................................................8-4
8.4 Event Actions...............................................................................................8-5
8.5 Event Classes ...............................................................................................8-6
8.6 Event Logging Thresholds...........................................................................8-7
8.7 Event Log Files............................................................................................8-8
Appendix A: Amendments ...................................................................................................1-1
Glossary..................................................................................................................... Glossary-1
Index ............................................................................................................................... Index-1
SMS-2700-INTRO-xxxx-UD10 v
Table of Contents Telepath SMSC Introduction Guide
vi SMS-2700-INTRO-xxxx-UD10
Telepath SMSC Introduction Guide List of Figures
List of Figures
Figure 1-1: Context of Telepath SMSC ................................................................................. 1-2

Figure 1-2: Hardware Configuration...................................................................................... 1-4
Figure 1-3: Telepath SMSC Architecture .............................................................................. 1-5
Figure 1-4: Short Messaging Entities................................................................................... 1-15
Figure 2-1: Classic Message Delivery ................................................................................... 2-3
Figure 2-2: Premium Message Delivery ................................................................................ 2-4
Figure 2-3: Express Message Delivery .................................................................................. 2-7
Figure 2-4: Express Message Queuing................................................................................... 2-8
Figure 2-5: Alert Notification on Express Messages ............................................................. 2-9
Figure 2-6: Real Time Billing .............................................................................................. 2-10
Figure 2-7: Message Completer Operation .......................................................................... 2-15
Figure 3-1: Source Address Validation.................................................................................. 3-2
Figure 3-2: Destination Address Validation .......................................................................... 3-3
Figure 3-3: Message Routing Process.................................................................................... 3-4
Figure 3-4: Pre-paid Message routing through Telepath SMSC............................................ 3-7
Figure 3-5: No Credit Available ............................................................................................ 3-8
Figure 3-6: Service Policy Set to Discard .............................................................................. 3-9
Figure 3-7: Service Down Policy set to Free ....................................................................... 3-10
Figure 3-8: Service Down Policy set to Error ...................................................................... 3-11
Figure 3-9: Subscriber Overcharged, SM Could Not be Delivered ..................................... 3-13
Figure 3-10: Delivery Attempt Acknowledgment ............................................................... 3-14
Figure 3-11: Retry Profile .................................................................................................... 3-15
Figure 3-12: Retry Scheme .................................................................................................. 3-16
Figure 3-13: MSC Address Storage ..................................................................................... 3-20
Figure 3-14: Dual-Mode Message Routing.......................................................................... 3-22
Figure 3-15: Dual-Mode Message Delivery......................................................................... 3-23
Figure 4-1: Customer Validation Process .............................................................................. 4-3
Figure 4-2: Extended Device Addressing .............................................................................. 4-4
Figure 4-3: Closed User Groups ............................................................................................ 4-8
Figure 6-1: Communication of Billing Processes (Part 1) ..................................................... 6-3
Figure 6-2: Communication of Billing Processes (Part 2) ..................................................... 6-4
SMS-2700-INTRO-xxxx-UD10 v
List of Figures Telepath SMSC Introduction Guide
vi SMS-2700-INTRO-xxxx-UD10
Telepath SMSC Introduction Guide List of Tables
List of Tables
Table 1-1: Telepath SMSC Core Processes ........................................................................... 1-6

Table 5-1: TON and NPI Address Translation File Numeric Values .................................... 5-4
Table 8-1: Event Classes ........................................................................................................ 8-6
Table 8-2: Sample Event Log Record .................................................................................... 8-8
Table A-1: Corrected Documentation Defects and Enhancements for UD2 ......................... 1-1
Table A-2: Corrected Document Defects and Enhancements for UD3 and UD4.................. 1-1
Table A-3: Document Enhancements for UD5 ...................................................................... 1-2
Table A-4: Document Enhancements for UD6 & UD7 ......................................................... 1-2
Table A-5: Document Enhancements for UD8 ...................................................................... 1-3
Table A-6: Document Enhancements for UD9-FOA............................................................. 1-3
Table A-7: Corrected Documentation Defects and Enhancements for UD9 ......................... 1-3
Table A-8: Corrected Documentation Defects and Enhancements for UD10 ....................... 1-3
SMS-2700-INTRO-xxxx-UD10 vii
List of Tables Telepath SMSC Introduction Guide
viii SMS-2700-INTRO-xxxx-UD10
Telepath SMSC Introduction Guide Preface
Preface
The Telepath Short Message Service Centre (SMSC) provides the functionality to send, deliver,
receive and store Short Messages (SMs) in a digital cellular network. This manual provides an
overview of the Telepath SMSC context and architecture and detailed descriptions on the
features of a Telepath SMSC. This preface comprises the following sections:
• Intended Readers
• Structure of this Document
• Related Documentation
• Typographic Conventions
• LogicaCMG Documentation
Note: This document corresponds to the Telepath SMSC software that is a component of
Telepath SMSC Release 2700, and also to any subsequent release, unless otherwise
indicated in technical notes or new documentation.
SMS-2700-INTRO-xxxx-UD10 ix
Preface Telepath SMSC Introduction Guide
Intended Readers
This document is intended for Telepath SMSC users who are responsible for implementing new
features on the Telepath SMSC. It is recommended that the reader have a working knowledge
of the operation and maintenance of the Telepath SMSC and a working knowledge of UNIX.
Structure of this Document
This document comprises the following components:
• Chapter 1: Context of Telepath SMSC

This chapter describes the features and functionality of Telepath SMSC.
• Chapter 2: Message Management

This chapter describes Standard and Express messaging modes and the different features
associated with each mode.
• Chapter 3: Message Validation and Routing

This chapter describes what happens to an SM when it reaches Telepath SMSC. It explains
the validation process and how each message is routed to its destination.
• Chapter 4: Provisioning Customers

This chapter describes all of the features relating to customer provisioning and provides
examples of how they can be used.
• Chapter 5: Platform Management

This chapter describes some specific network features that are applicable across the
platform.
• Chapter 6: Billing Customers

This chapter describes the billing component. A description of the billing processes and
the contents of the billing file are provided.
• Chapter 7: Monitoring the System

This chapter describes the tools that are available to monitor Telepath SMSC processes
and monitor resources, such as CPU.
• Chapter 8: Event and Alarm Management

This chapter provides information on Events and Alarms within the system, and describes
the Event Handler.
• Appendix A: Amendments
This chapter outlines the new features and functionality of Release 2700 that are described
in this document.
• Glossary
• Index
x SMS-2700-INTRO-xxxx-UD10
Some headings will feature an asterisk (*). This indicates that new feature(s) have
been added, enhancing the functionality of the Telepath SMSC 2700. For more
information, or to have this feature added to your current system, please contact
your local LogicaCMG representative.
Related Documentation
The document provides an overview of the Telepath SMSC and describes the administration
and management tasks relating to it. It should be read in conjunction with the following books:
• Telepath SMSC Configuration Guide

• Telepath SMSC Maintenance Guide
• TPSMT User’s Guide
SMS-2700-INTRO-xxxx-UD10 xi
Typographic Conventions
The following conventions are used in the text of this document to distinguish particular types
of information:
Special Emphasis in Text

The following table shows the types of emphasis used to distinguish particular elements in the
text of this document:
Font Convention Identifies
Bold Command names, variable values, field values and executables.
Italic Filenames, pathnames, variable names, field names and

references to other documents.
Monospace File contents, program output and code examples.
Monospace Bold Commands and text that users are instructed to enter at the
keyboard.
Arial Text labels in illustrations.
Special Characters in Text

The following table shows characters that have special meaning in the text of this document:
Character Identifies
<> Variables to be specified by the user in command or file input

are enclosed in angle brackets.
\ Continuation character in commands or lines of code that are

broken because of space restrictions on the page.
$ UNIX prompt for commands to be entered in the Bourne shell.
% UNIX prompt for commands to be entered in the C shell.
xii SMS-2700-INTRO-xxxx-UD10
LogicaCMG Documentation
A documentation CD accompanies the software you have received from LogicaCMG.
Ordering Documentation
To order extra copies of LogicaCMG documentation in either hardcopy or softcopy format,
contact your LogicaCMG account manager or send an email to mndocs@logicaCMG.com.
Customer Feedback
In order to maintain the high standard of service that LogicaCMG provides, we welcome any
suggestions and comments that you may have on the quality and usability of the documentation.
A Reader’s Comment Form is included at the back of this document. We would be grateful if
you could take the time to complete this form and return it to us at your earliest possible
convenience.
Please submit any comments that you may have to this address:
Customer Training and Documentation Department

LogicaCMG
Mobile Networks Division
Custom House Plaza 5
Harbourmaster Place
Dublin 1
Ireland
Telephone #: (353) 1 819 3400

Fax #: (353) 1 819 3401
e-mail: mndocs@logicaCMG.com
SMS-2700-INTRO-xxxx-UD10 xiii
xiv SMS-2700-INTRO-xxxx-UD10
Telepath SMSC Introduction Guide Context of Telepath SMSC
1. Context of Telepath SMSC
This chapter comprises the following sections:
• Overview of Telepath SMSC

• Telepath SMSC Local Environment
• *Customer Care Server
• Application Interfaces
• Telepath SMSC External Environment
SMS-2700-INTRO-xxxx-UD10 1-1
Context of Telepath SMSC Telepath SMSC Introduction Guide
1.1 Overview of Telepath SMSC
The Telepath SMSC system provides the functionality to send short messages (SMs) from one
Short Message Entity (SME) to another. Short messages are text-based, limited-length
messages, as defined by the appropriate telecommunications standards, for example, GSM. An
SME is usually a mobile handset, but can also be any electronic device capable of transmitting
or receiving text messages, for example, a computer terminal, or a Voice Mail system.
The Telepath SMSC system consists of the Telepath SMSC software and a UNIX platform
(hardware, operating system, and related software) on which the Telepath SMSC software runs.
Figure 1-1 provides an overview of Telepath SMSC
Non-MS Mobile Station

External Short Short Message Other
Message Entity Entity Services/
(ESME) (SME) Applications
Telepath
SMSC
Provisioning Billing System
Network
Management System
Figure 1-1: Context of Telepath SMSC
The processes of Telepath SMSC correspond to the following three stages in the lifecycle of
short messages:
• Processes responsible for the submission of short messages and subsequent delivery into
Telepath SMSC (transmitters)
1-2 SMS-2700-INTRO-xxxx-UD10
• Processes responsible for scheduling and storing of messages (Telepath SMSC core
processes)
• Processes responsible for accepting messages and routing them to a final destination
(receivers)
The context within which Telepath SMSC operates can be divided into:
1. The Local Environment. This consists of:

• Hardware configuration
• Third-party software
• Telepath SMSC software
See “Telepath SMSC Local Environment” on page 1-4 for more information.
2. The External Environment. This consists of applications and services with which Telepath
SMSC interacts. Such as:
• Short Message Entities (mobile and non-mobile)
• Application services, for example, Voice Mail Systems, or Paging Bureaus
See “Telepath SMSC External Environment” on page 1-14 for more information.
1.2 Telepath SMSC Local Environment
The Telepath SMSC local environment consists of hardware configuration, proprietary

software, and Telepath SMSC software, as described in the following sections.
1.2.1 Hardware Configuration
The Telepath SMSC runs on a HP or Lucent platform both running HP-UX 11 Operating
System. Figure 1-2 shows the hardware platform.
SIU/
TSU
Hardware
Platform
Figure 1-2: Hardware Configuration
This diagram contains references to an SIU and a TSU. An SIU is the Signalling Interface Unit
and it provides the connectivity between the SS7 platform and the SS7 network. The TSU is the
Telecom Signalling Unit and it provides the same functionality as an SIU. For more information
on SS7, refer to the Telepath SMSC Maintenance Guide.
For more information on recommended disk configurations and memory sizing, refer to the
Telepath SMSC Feature Description.
1.2.2 Proprietary Software
The Telepath SMSC software environment (except for the Telepath SMSC software itself) may
consist of the following:
• HP-UX 11 Operating System

• Oracle8i Server
• Signalling interface system, for example SS7, SINAP
• File Transfer, Access and Management (FTAM) communications software
• TCP/IP incorporating File Transfer Protocol (FTP)
• X.25 software
Figure 1-3 illustrates the architecture of Telepath SMSC.
Application Interface Modules
Telepath Core Processes
SS7 RDBMS
UNIX Operating System
Figure 1-3: Telepath SMSC Architecture
1.2.3 Telepath SMSC Software
The core processes that are part of a default installation of the Telepath SMSC are described in
Table 1-1.
Process Name Description
tpkernel Messages are accepted from transmitter interfaces and routed through receiver
interfaces via tpkernel. tpkernel determines whether messages are retried.
tpkernel is also responsible for reserving and structuring memory for other
Telepath processes during startup.
tpevent This process is responsible for monitoring Events within Telepath SMSC, or
any related applications. All Events are logged and must be monitored regularly
by the System Administrator to ensure no serious errors occur on the system.
tpspooler This process updates the cdrstat table in the database, creates a CDR for each
short message and puts each CDR in a billing file.
tpcdrpostpp tpcdrpostpp reformats the billing files created by Telepath SMSC and also
provides additional statistical information if required.
tptimer If tpkernel receives a Scheduled message, the message is stored in the database.
tptimer periodically examines the database and informs tpkernel about any
outstanding message deliveries which are to be attempted. tptimer changes the
state of a message from Scheduled to For Delivery before sending it to
tpkernel. If a Scheduled message is submitted for delivery and the scheduled
date is in the past, then it is treated as a normal message.
tptimer also periodically generates a statistic Event to tpevent to cause a
logging of Event statistics.
tpmonitor This is a stand alone process which has a monitoring function within Telepath
SMSC and is responsible for ensuring that the system is resilient in the event of
a process failure.
tpsme_init tpsme_init is responsible for initialising the shared memory database during a
cold startup.
tprmt This is LogicaCMG’s resource management tool, which is used to monitor

resource use such as CPU and filesystems.
tpsa tpsa is the SNMP Subagent which is used in Telepath SMSC to facilitate
routing of system performance data to an external network management
system. Refer to the SNMP Subagent Configuration Guide for
information on tpsa.
Table 1-1: Telepath SMSC Core Processes
Process Name Description
tpcompleter After each delivery attempt, tpkernel receives an acknowledgement to say

whether a message was delivered successfully. On receipt of this
acknowledgement, certain fields of the message in the database are updated, for
example, the state and status. tpcompleter changes the state of each message to
Done.
By default four tpcompleter processes are running. However if you are using a
Premium configuration only one tpcompleter process is required.
tpTCLmonitor tpTCLmonitor is responsible for validating the operation and configuration of

some Telepath services, such as, the messaging and billing services. It tests
these services and updates some tables in the Management Information Base
(MIB).
tpproxy_DAP This process is used to start the Distributed Administration and Provisioning
(DAP) interface.
Table 1-1: Telepath SMSC Core Processes (Continued)
1.3 *1Customer Care Server
In premium messaging, messages which have reached a Done state may be overwritten at any
time due to the method of storage used. This is known as a Premium Message Store. The
Premium Message Store storage system consist of a series of UNIX data files and is constantly
purged by new messages overwriting old or Done messages. Done messages can not be reliably
viewed through the DAP portal. The Customer Care server allows for premium messages in a
Done state to be viewed reliably through the DAP portal by storing them on the Customer Care
server. These messages are stored in a short-msg table for a period of seven days. After seven
days they are moved to the deadshort_msg table for archiving to an off-line Archive Record
Store. Messages stored on this server will contain message text to a maximum of 16 characters.
See Chapter 2 for details.
Note: The off-line Archive Record Store is provided but not managed by LogicaCMG.
1. Some headings will feature an asterisk (*). This indicates that new feature(s) have been
added, enhancing the functionality of the Telepath SMSC 2700. For more information, or to
have this feature added to your current system, please contact your local LogicaCMG
representative.
1.4 Application Interfaces
There are a number of external services and applications with which Telepath SMSC interacts.
The following is a list of possible external services and interfaces available:
• Mobile Network
• Short Message Peer to Peer (SMPP)
• Network Management System (NMS)
• Telepath SMSC System Manager Terminal (TPSMT)
• Distributed Administration and Provisioning (DAP) interface
• Remote Administration and Provisioning (RAP) interface
• Telocator Alphanumeric Protocol (TAP)
• Telocator Network Paging Protocol (TNPP)
• Universal Computer Protocol (UCP)
• Sierra
• Telepath SMSC Provisioning Customers (CAI)
• Distributed Metrics Management (DMM) interface
• Short Message Peer to Peer Provisioning (SMPP-P)
The following sections describe these interfaces.
Note: It is important to remember that each Telepath SMSC installation is customer specific,
and may not support all of these interfaces.
1.4.1 Mobile Network Interface
The Telepath SMSC interface to the Mobile Network is accomplished through a dedicated
interface referred to as the Mobile Network Interface (MN-IF). This interface runs on top of the
SS7 stack. The MN-IF is responsible for:
• Receiving short messages from tpkernel for delivery to mobile stations

• Retrieval of routing information from the appropriate HLR for each short message to be
delivered
• Providing reports to tpkernel indicating success or failure of a Mobile Network delivery
attempt
• Receiving alerts from the Mobile Network and routing them to tpkernel
• Forwarding Mobile Originated messages to tpkernel
For more information on MN-IFs, refer to the individual Mobile Network Interface
Configuration Guides (GSM, ANSI-41-CDMA, ANSI-41-TDMA and PDC).
1.4.2 Short Message Peer-to-Peer Interface (SMPP)
The interface between the Telepath SMSC and other non-PLMN (Public Land Mobile
Network) SMEs, for example, Paging or Voice Mail Systems, can be implemented over X.25
or TCP/IP. Non-PLMN SMEs, referred to as External Short Message Entities (ESMEs), submit
SMs and queries to the Telepath SMSC and the Telepath SMSC forwards query responses and
submits SMs (for example, delivery receipts) to the ESME. All messages sent, in either
direction, generate an immediate response.
Example: Voice Mail System (VMS)
When a voice mail message is received by Telepath SMSC from an ESME, the
Telepath SMSC extracts the voice mail values from the message. Normally, this
includes an index to retrieve one of a number of predefined short message texts from
the Telepath SMSC database. For additional information on predefined short
messages, refer to the SMPP Interface Configuration Guide.
Having retrieved the appropriate text, Telepath SMSC combines the text and the
numeric values from the voice mail message, determined by the format defined in the
predefined message text, to construct a short message for transmission to the mobile
subscriber.
This information is submitted to tpkernel with the specified address as the

destination and the ESME address as the source. The message replaces any
undelivered short message with the same source and destination addresses if submit-
replace is specified.
The short message is configurable by the system administrator. Typically there is a

requirement for the message to include a call back number for the subscriber.
For information on the SMPP Interface, refer to the SMPP Interface Configuration Guide.
1.4.3 Network Management System Interface (NMS)
Network Management System (NMS) is an external service within which Telepath SMSC
interacts.
Telepath SMSC may provide two possible interfaces to the NMS depending on your specific
configuration.
1. A Transmission Control Protocol/Internet Protocol (TCP/IP) socket interface for Event

notification to the NMS. The NMS acts as a “server” and Telepath SMSC as a “client”.
The Telepath SMSC begins a connection to a new TCP/IP service on the NMS. Telepath
SMSC then transfers Event messages (text string) to the NMS. The NMS relays a response
to the Telepath SMSC.
2. An SNMP (Simple Network Management Protocol) interface using the Telepath SMSC
SNMP Agent and MIB (Management Information Base). For more information on SNMP
refer to the SNMP Subagent Configuration Guide.
1.4.4 System Manager Terminal (TPSMT)
The Telepath SMSC System Manager Terminal (TPSMT) provides a highly configurable
interface for Telepath SMSC operators and system administrators for performing a wide range
of system administration, operations and maintenance functions. For further information on the
TPSMT application, refer to the TPSMT User’s Guide.
1.4.5 Distributed and Remote Administration and Provisioning
Distributed Administration and Provisioning (DAP) module provides a user-friendly, Web-

based interface for operators performing functions, such as message management and
subscriber provisioning. Refer to the DAP User’s Guide for a full description of the DAP
interface.
Telepath SMSC Remote Administration and Provisioning (RAP) interface is a command-line

interface providing similar functionality to the DAP interface. It lets you add subscriber records
remotely using an ASCII-based protocol. It also lets you export provisioned data from Telepath
SMSC to other applications. The RAP services that are supported include message
management, SME management and subscriber management.
Refer to the RAP User’s Guide for a full description of the RAP interface.
1.4.6 Customer Message Entry System (TPCUST)
The Telepath SMSC Customer Message Entry System (TPCUST) provides an interface for
communication between subscribed customers of the Short Messaging System and destination
SMEs. Options include viewing, sending, accepting, replacing and deleting short messages.
Refer to the TPCUST User’s Guide for a full description of the TPCUST application.
1.4.7 Telocator Alphanumeric Protocol Interface (TAP)
This Interface is responsible for the support of message submission from TAP clients to mobile
stations through the PLMN.
The TAP Interface allows a remote device to send information to the Telepath SMSC through
Hayes compatible modems or over TCP/IP from the TAP clients such as:
• IBM PCs or compatibles (using the Notify! or NextNode software package)

• Apple Macintoshes (using the Notify! or NextNode software package)
• National Dispatch Centre proprietary paging system
• Alphamate
Upon successful connection with the Telepath SMSC, the TAP client submits the prepared
message and attempts delivery to the Telepath SMSC. A response is sent to the TAP client from
the Telepath SMSC indicating if message submission was successful. If submission was
successful, the message is forwarded to the designated mobile station.
The TAP Interface is managed and maintained using TPSMT.
Refer to the TAP Interface Configuration Guide for a full description of the TAP Interface.
1.4.8 Telocator Network Paging Protocol (TNPP)
TNPP is a point-to-point digital communications protocol that has become a paging industry
standard for communicating between Paging Terminals. This protocol was developed to meet
the demand for multi-city, regional, and nationwide paging services.
The TNPP Interface provides the following functionality:
• Submission of short messages to the Paging Network from Telepath SMSC.

• Receipt of paging messages from a Paging Terminal and submission of these as short
messages to Telepath SMSC.
• Escalation of short messages that have reached a timeout period for delivery to a Paging
Device over the Paging Network. This means that the short messages are routed to the
Paging Network for delivery to the subscriber’s numeric or alphanumeric pager.
Refer to the TNPP Interface Configuration Guide for a full description of the TNPP Interface.
1.4.9 Universal Computer Protocol (UCP)
Universal Computer Protocol (UCP) is an interface used by external systems to access paging
services. The UCP Interface is responsible for the support of message submission from UCP
clients to Telepath SMSC through the PLMN. UCP is suitable to run over X.25 or TCP/IP in
the Public Switched Telephone Network (PSTN). The UCP Interface inserts UCP short
messages into the short_msg table. It uses the Customer table to validate the originating party
of the message if validation is switched on.
The UCP Interface provides the following functionality:
• Accepts connections from a number of remote UCP client applications; the maximum
number of connections is thirty-two
• Responds to operation requests from UCP client applications
• Returns a delivery result of these messages to the UCP client
• Validates operation request messages through syntax checking, and parameter checking.
A negative result message is sent to the client if validation fails
• Validates the originator of the short message. If validation fails, a negative result message
is sent to the client
• Stores the short message and notifies the kernel
• Broadcasts short messages to multiple destinations
• Provides storage of short messages for later delivery
• Generates statistics
• Provides error handling for both protocol errors and internal errors
Refer to the UCP Interface Configuration Guide for a full description of the UCP Interface.
1.4.10 Sierra Interface
The Telepath SMSC provides an interface to the Octel Sierra System. The Octel Sierra System
provides the required interaction with the PLMN and the PSTN, to inform subscribers that there
is a voice mail present in their voice mailbox, and of forwarding alphanumeric pages to the
subscribers, collected via the VMS/IVR (Voice Mail System/Interactive Voice Recognition)
system and DTMF equipped phones.
Refer to the Sierra Interface Configuration Guide for a full description of the Sierra Interface.
1.4.11 Distributed Management Metrics Module (DMM)
The Distributed Management Metrics Module (DMM) is a Web-based user interface for
generating and viewing statistics on the Telepath SMSC. The client is implemented in Java and
can run on the Netscape navigator browser. It provides statistical information on:
• Overall short message usage

• Peak message time
• Message transmission success rates
• Network and computing resource utilisation
• Specific service utilisation
• Customer usage profiles
• User group usage profiles
The DMM can run both on-platform and off-platform.
Refer to the DMM User’s Guide for a full description of the DMM.
1.4.12 * Prepaid Gateway (tpprepaidg)
The Prepaid Gateway (tpprepaidg) provides an interface between the Telepath SMSC and an
External Billing System (EBS). When the prepaid process is enabled, each SM is examined by
Telepath SMSC to determine if it is prepaid. Only prepaid SMs are sent to tpprepaidg.
tpprepaidg through its interaction with the EBS provides prepaid validation. Depending on the
response from the EBS, tpprepaidg updates the database with the intermediate state and status
of the prepaid SM. These provide information about the prepaid SM which is essential in
determining subsequent actions. These states and their status are described in section 2.8 on
page 2-12. When a prepaid SM reaches a state of For Delivery, tpprepaidg informs tpkernel
to deliver the message.
1.5 Telepath SMSC External Environment
The Telepath SMSC external environment consists of Short Message Entities, application
services, and interfaces. The following subsections summarise the components of the external
environment.
1.5.1 Short Message Entities
A Short Message Entity (SME) is any source (originator) or sink (recipient) of short messages.
The entity is either inside or outside the Public Land Mobile Network (PLMN), for example, a
mobile handset. When short messages are received by an SME inside the PLMN, the messages
are considered to be Mobile Terminated (MT). When short messages are originated by an SME
which is inside the PLMN, the messages are termed Mobile Originated (MO).
Since a common use of the Telepath SMSC is to relay short messages from one SME within the
PLMN to another SME within the PLMN, the same message can be considered both Mobile
Originated, as well as Mobile Terminated.
Figure 1-4 illustrates some of the different short message entities.
MS
E-Mail
Telepath SMSC
VMS MS
Paging Bureau
VMS Voice Mail System
MS Mobile Station
Figure 1-4: Short Messaging Entities
Note: An External SME (ESME) is a non-mobile entity. This interaction with the Telepath
SMSC is not defined within the standards. An ESME is specific to an individual
operator’s network and the particular application services in use. However, the generic
architecture of the Telepath SMSC allows for support of ESMEs.
Telepath SMSC Introduction Guide Message Management
2. Message Management
• Short Messaging Modes

• Classic Messaging
• Premium Messaging
• *Customer Care for Premium Messaging
• Express Messaging
• *Real Time Billing
• Message Types
• Short Message States
• Message Lengths
• Short Message Responses
• Predefined Messages
• Registered Messages
• Message Completion
Message Management Telepath SMSC Introduction Guide
2.1 Short Messaging Modes
Telepath SMSC provides two modes of Short Messaging, Standard and Express. Each mode is
explained below.
Standard Messaging: this is the Store-and-Forward messaging on Telepath SMSC. It is

divided into two types that are defined according to where the messages are stored. They can
be stored in the Relational DataBase Management System (RDBMS) or in datafiles. Messages
that are stored in the RDBMS are called Classic messages and messages that are stored in
datafiles are called Premium messages. Standard messages can be up to 160 bytes in GSM
networks and 255 bytes for ANSI-41 networks. Each of these types of Standard messaging are
explained below:
Classic Messaging: this type of messaging provides reliable message delivery, retry and
storage. The message is stored in the RDBMS. For more information see “Classic
Messaging” on page 2-3.
Premium Messaging: this type of messaging provides high speed message throughput
where messages are securely stored in UNIX flat files. For more information see
“Premium Messaging” on page 2-4.
Express Messaging: this type of messaging provides the highest speed throughput for
messages of up to 1500 bytes in size (GSM and ANSI-41 networks). When the Transmitter
Interface receives the message, validation is performed, it is forwarded onto tpkernel and an
immediate delivery attempt is made. The message does not get stored in the disk database or in
the datafiles, but it is temporarily stored in the shared memory database. The Express messages
are given highest priority on the Telepath SMSC, in other words they are always inserted at the
head of the message queue.
On Telepath SMSC you can configure your system with a combination of Express messaging
with either Classic or Premium. For more information on setting the messaging mode, refer to
Chapter 3 of the Telepath SMSC Configuration Guide.
2.2 Classic Messaging
This type of messaging is based on Store-and-Forward where all SMs are stored in the RDBMS.
This provides a secure location for the SMs. Classic messaging is optional on your Telepath
SMSC.
When a Transmitter Interface (Tx) receives a Classic Short Message, it stores the message in
the short_msg table in the Relational Database Management System (RDBMS), then it notifies
tpkernel of the new message. tpkernel updates the shared memory database and then routes
the message out to the appropriate Receiver Interface (Rx).
When a Classic Short Message is submitted to the Telepath SMSC, the action tpkernel takes
to ensure delivery depends on the current state of the destination SME.
Normally, the SME switches between the Available and the Busy states. The state of an SME
can be queried via the Sme.Query command in TPSMT.
Figure 2-1 illustrates how a Classic message is routed through Telepath SMSC.
stores message (short_msg table)

Tx
1 RDBMS
forwards details
2 to tpkernel
tpkernel
updates database
routes message out to Rx
3
4
Shared Memory
Database
Rx
Figure 2-1: Classic Message Delivery
1. The Transmitter Interface (Tx) receives a short message and stores it in the short_msg
table in the RDBMS.
2. It then forwards the message onto tpkernel.
3. tpkernel updates the shared memory database.
4. A delivery attempt is then made.
For a Classic Message tpkernel maintains an internal table, which contains a list of all SMEs
which currently have messages pending in the database. This table is the primary source of
delivery management information. It is the main structure used by tpkernel for storing
messages queued for each SME, and also for tracking SME states before attempting to deliver
a message.
2.3 Premium Messaging
This type of messaging is based on Store-and-Forward but the messages are stored in datafiles
instead of in the Oracle RDBMS. Premium messaging is optional on your Telepath SMSC and
can be used instead of Classic messaging. It provides a higher throughput than Classic
messaging.
When an SM arrives at the Telepath SMSC, it is stored in a datafile. The datafiles are created
at installation and are named collectively as the Fast Message Store (FMS). Premium
messaging allows for the same functionality as Classic messaging, such as message retry and
message billing. However, because the messages are not stored in the Oracle RDBMS, message
processing may be faster.
An Oracle database is still required on a Premium messaging configuration to store system

configuration data.
Figure 2-2 illustrates what happens when a Premium message is forwarded to Telepath SMSC.
stores message
FMS
Tx 1
forwards details
2 to tpkernel
tpkernel
updates database
routes message to Rx
3
4
Shared Memory
Database
Rx
Figure 2-2: Premium Message Delivery
1. The transmitter Interface receives a short message and stores it in the FMS.
2. It then forwards the message onto tpkernel.

Note: Just like Classic messaging, Premium messages are retried based on the set of Standard
retry profiles.
2.3.1 Premium Message Operations
It is only possible to reliably query messages that are still in a For Delivery state, as other
messages may have been overwritten in the FMS once they reach a Done state.
Premium messaging supports the operations possible through SMPP, for example:
• submit-and-deliver
• submit-with-replace
• query
• delete
• replace (based on Message ID)
• Receipt generation
• query and delete (based on originating address and operator message reference)
For more information on the SMPP operations, refer to the SMPP Interface Configuration
Guide.
The following options, however, are not supported:
• Distribution List queries

• Completed message replacement
If you want to view a message, use the menu option Messages.View in TPSMT1.
1. You can also view a message through the DAP Interface. For more information, refer to the
DAP User’s Guide.
2.4 *1Customer Care for Premium Messaging
Customer Care for Premium messaging enables customers to view premium messages that have
been delivered. It also provides a long-term store for Done messages.
Using the DAP interface you can view messages from both the premium message store and the
message archive. Both active and completed messages are available temporarily to the
customer care representative.
Customer Care for Premium messaging is enabled through the use of a customer care server.
The customer care server is activated by the configurable parameter
smsc_premium_store_enabled_swt. Refer to the Telepath SMSC Configuration Guide for more
information on this feature.
Note: A single CCP Server can collect information from multiple Telepath SMSCs or from a
single Telepath SMSC. Also, multiple CCP servers can be used with multiple Telepath
SMSCs or a single Telepath SMSC.
To use the Customer Care for Premium messaging functionality, ensure you have the
appropriate license. To obtain this license, please contact your account manager.
1. Some headings will feature an asterisk (*). This indicates that new feature(s) have been
added, enhancing the functionality of the Telepath SMSC 2700. For more information, or to
have this feature added to your current system, please contact your local LogicaCMG
representative.
2.5 Express Messaging
When a Transmitter Interface receives an Express message, it forwards it to tpkernel and it is

stored in the shared memory database.
Figure 2-3 illustrates how an Express message is routed through Telepath SMSC.
Tx
forwards message
1
tpkernel
updates database routes message out to Rx

2 3
Shared Memory
Database Rx
Figure 2-3: Express Message Delivery
1. The transmitter Interface receives a short message.

2. It forwards the message onto tpkernel.
Note: Express messages are not stored in the RDBMS or FMS.
2.5.1 Express Message Queues
Each message is stored in shared memory. Express messages are given highest priority in the
queue. In other words, they take precedence over Standard messages. This ensures that Express
messages are always inserted at the head of the queue.
Figure 2-4 illustrates how Express messages are queued in the shared memory database.
SME A SM1 SM2 SM3 SM4
Express Express Priority Normal
Figure 2-4: Express Message Queuing
To avoid the queue growing too large and Standard messages expiring, a limit is imposed on
the number of express messages you can store in the queue. Before tpkernel creates an entry
in shared memory, it finds out if the message is destined for an ESME or a mobile station. It
retrieves this information from the bind data that is passed from the Transmitter Interface. Once
it has determined where the message is destined for, queue sizing takes place.
1. ESME Queue
The configurable parameter smsc_max_ESME_express_sm_q_len is set to 100 messages
by default.
2. Mobile Terminated Queue

The configurable parameter smsc_max_express_sm_q_len is set to 10 messages by
default.
Note: Exceeding the limit on queue size results in Express messages being rejected and a
response being sent back (if requested) to the originating address.
2.5.2 Express Message Retry
Express messages are assigned a short-term retry. A default retry profile is assigned to Express
messages. For more information on retry profiles, see the TPSMT User’s Guide. According to
the Express Message retry schemes, all Express messages are retried based on one level of the
retry scheme. If the retry is unsuccessful and the message cannot be delivered the message is
rejected. When this happens all remaining Express messages in the queue of pending messages
for that particular SME are deleted as it is expected that delivery of subsequent messages to that
SME will not succeed either.
2.5.3 SMS Alert Notification on Express Messages
A transmitter ESME can request to be notified when an MS becomes active. The Telepath
SMSC receives an Alert from the network when an MS becomes available to receive SMs. It
can then notify the ESME of this and in turn trigger a delivery attempt.
Figure 2-5 illustrates the Alert Notification process.
1 Tx 2
ESME1 tpkernel
“DPF=Y”
SME A
DPF=Y
SM1 SM2
Alert Required
Express Express
Figure 2-5: Alert Notification on Express Messages
1. The ESME submits a short message for SME A. As part of the message details, the
Delivery Pending Flag (DPF) is set to “Y”.
2. The Tx forwards the short message onto tpkernel.
Note: Even if the DPF flag is only set on one short message and the rest of the messages for
that SME are not, the overall state of the SME is set as Alert-Required.
When tpkernel receives the Alert Notification from the Mobile Network Interface indicating
the availability of the SME, a message is sent to the ESMEs that requested them, and the DPF
is no longer set for that ESME.
For information on how to clear the DPF, refer to Chapter 3 of the Telepath SMSC
Configuration Guide.
2.6 *Real Time Billing
Real Time Billing allows subscriber’s accounts to be updated in real time by allowing TLV
billing data generated for Done messages to be spooled in real time to a separate Billing
Management System (BMS) application.
Note: It is the customer’s responsibility to have an application running on the BMS which
will receive the TLV data, parse it and process it as required.
TLV data is sent to the BMS by a process called rtspooler which is spawned from tpspooler.
This allows data to be sent to the BMS without affecting the tpspooler performance.
Figure 2-7 below illustrates the Real Time Billing feature and its interaction with the Telepath
server.
Telepath SMSC
1
tpkernel
3 TLV files in
CDR directory
tpspooler
5a
5 Billing
rtspooler Management
System
5c
5b
TLV files in
bms_unsent_tlv
directory
Figure 2-6: Real Time Billing
1. Short Messages are sent to tpkernel.

2. tpkernel sends billable messages and test messages to tpspooler.
3. tpspooler writes TLV data to the file specified by the configurable parameter cdr_dir.
4. tpspooler sends the TLV data via an IPM connection to rtspooler.
5. rtspooler sends the TLV data to the external BMS via a TCP connection.
Error Cases
5a. If the TCP connection to the BMS is congested rtspooler stores the TLV records
in a temporary queue. When the congestion has cleared the TLV data is sent to the
BMS. Up to 2,500 TLV records can be stored in a temporary queue until the
connection is restored.
5b. If the connection with the BMS is not restored and the temporary queue is full
(2,500 TLV records are stored), the TLV data in the temporary queue is written to
file. The directory where the file is stored is specified by the configurable
parameter spooler_bms_tlv_dir (default value is bms_unsent_tlv).The temporary
queue is used until the congestion in the socket clears. TLV data written to file
must be transferred to the BMS by the customer via FTP.
5c. If the connection with the BMS breaks, the event CDR_BMS_CONN_FAIL is
raised, and rtspooler writes the TLV data directly to file. The directory where this
file is stored is specified by the configurable parameter spooler_bms_tlv_dir. TLV
data written to this file must be transferred to the BMS by the customer via FTP.
The number of seconds that rtspooler must wait between reconnection attempts to
the BMS can be configured by the configurable parameter bms_reconnect_intvl.
Refer to the Telepath SMSC Release 2700+ Configuration Guide for more
information on events, error codes and configurable parameters.
6. The BMS receives the TLV data. The application running on the BMS must parse and
process the TLV data. It is the customer’s responsibility to have this application running
on the BMS.
2.6.1 Starting Real Time Billing
Real Time Billing is enabled by the configurable parameter spooler_enable_bms_swt. When

this parameter is set to Y, data will be sent to the BMS in real time. The configurable parameter
spooler_enable_bms_swt is checked at initilisation only. This means that it is not possible to
turn Real Time Billing on and off on the fly.
The hostname and port number of the BMS are supplied to the spooler in the configurable
parameters spooler_bms_host and spooler_bms_service.
For more information on the configurable parameters mentioned above please refer to the
Telepath SMSC Release 2700+ Configuration Guide.
To start the Real Time Billing feature follow the steps below:
1. Login to TPSMT as the user telepath.

2. Go to the Control/ Params/ Modify menu.
3. Change the value of the configurable parameter spooler_enable_bms_swt to Y.
4. Ensure the configurable parameters spooler_bms_tlv_dir and bms_reconnect_intvl are set
to the correct values (refer to the Telepath SMSC 2700+ Configuration Guide).
5. Restart Telepath SMSC.
2.6.2 Stopping Real Time Billing
tpspooler signals rtspooler to shutdown. If rtspooler has not shutdown within 1.5 seconds
tpspooler sends it a kill signal. When rtspooler recieves a kill signal it finishes processing any
data it is working on, moves any tlv records in it’s send queue to file, closes all files and socket
connections and exits.
To stop the Real Time Billing feature follow the steps below:
1. Login to TPSMT as the user telepath.

2. Go to the Control/ Params/ Modify menu.
3. Change the value of the configurable parameter spooler_enable_bms_swt to N.
4. Restart Telepath SMSC.
For more information on TPSMT, refer to the Telepath SMSC Release 2700 TPSMT User’s
Guide.
It is not possible to turn Real Time Billing on and off on when Telepath SMSC is running. If
rtspooler fails tpspooler raises a CDR_BMS_CONN_FAIL event and will do a graceful
shutdown. If tpmonitor is running it will restart tpspooler which in turn will restart rtspooler.
2.7 Message Types
Standard messages can be of type Normal, Priority, or Scheduled. These message types are
assigned by the message originator when a short message is being submitted, and they
determine the order in which messages are forwarded by tpkernel to be delivered to their
destination:
• Normal messages are delivered with no special treatment.

• Priority messages are messages which are to be delivered urgently. Priority messages are
delivered ahead of Normal messages.
• Scheduled messages are messages which are to be delivered at a specific date and time.
When the scheduled date and time is reached, the message is delivered. If a Scheduled
message is submitted for delivery and the scheduled date is in the past, then the message
is treated as a Normal message.
For more information on sending a Priority or a Scheduled message from TPSMT, refer to the
TPSMT User’s Guide.
Note: Express messages are delivered ahead of all of the above. For more information see
section 2.5.1 on page 2-7.
2.8 Short Message States
Every short message has a state associated with it. In order to track the progress of an SM,
tpkernel associates a state information element with each SM which it receives. There are three
message states, as follows:
For Delivery Once a message has been inserted in the database by the
Transmitter Interface, it is in a For Delivery state. A delivery
attempt is then made.
Scheduled When message delivery is scheduled by the customer to be sent at
a future date and time, the message is set to a Scheduled state.
Done If, for example, a message is delivered successfully, it has reached
the final state, Done. There are a variety of reasons why a message
may be assigned a state of Done. These are described below.
The Done state can be further subdivided into one or more substates, referred to as the message
status. The following is a list of possible message status:
Delivered The message has been successfully delivered to the SME.

Deleted The message was deleted before successful delivery to the SME.
Expired The message exceeded its validity period before successful deliv-
ery. The status Expired occurs if a message could not be delivered
on time if, for example, tpkernel received a number of temporary
error.
Accepted When a message is accepted from the TPSMT interface, it is
marked as read and taken out of the queue to be delivered.
Undeliverable Some permanent error condition other than Expired or Deleted
prevented the message from being delivered (for example, a per-
manent network error, such as a subscriber not being provisioned
in the HLR or the subscriber being barred at the HLR).
Rejected A scheme is defined to reject a single message at the top of a
queue for a particular destination SME, but subsequent messages
in queue will not be attempted.
2.9 Message Lengths
Message Lengths may vary on the Telepath SMSC. For example, WAP SMs may be up to 1500
bytes in length, whereas Standard SMs can be up to 225 bytes in length, depending on your
network technology. The maximum message length of a Standard SM (Premium or Classic) is
configurable and can be set at any value between 0 and 255 bytes. The maximum message
length for an Express SM is set to 1500 bytes and is not configurable. The maximum length for
Predefined SMs is 160 bytes.
For more information on Message Lengths, refer to Chapter 3 of the Telepath SMSC
2.10 Short Message Responses
The message response is similar to a message receipt, except that it is application oriented and
not user oriented. For an ESME to request a Response you must set the response-request
Indicator on. For information on the contents of a Message Response refer to the SMPP
Protocol Specification v3.3/3.4.
2.11 Predefined Messages
A predefined message is a re-usable text string that is stored in the Telepath SMSC under a
unique identification number. They are used primarily for Voice Mail systems. A predefined
message is created on the Telepath SMSC using the Messages.Predefined.Add menu in
TPSMT. For more information, refer to the SMPP Interface Configuration Guide.
2.12 Registered Messages
Under normal circumstances, a message originator receives no indication that the message has
been delivered to its destination. For some messages, the sender might like to be notified when
the message sent has reached a final state. In order to receive a receipt, a message must be
registered.
2.12.1 Registering Messages Submitted from TPSMT
A receipt can be requested for messages submitted from TPSMT by setting a value in the
Registered field in the Send a Message command form. This forces tpkernel to send a receipt,
in a new SM to the message originator.
Refer to the TPSMT User’s Guide for detailed information on values for the Registered field.
2.12.2 Mobile Originated Registered Messages
Mobile originated messages can also be registered. MO short messages for multi-recipients or
Distribution Lists cannot be marked as registered. Only some phones give a subscriber the
option to register MO messages. Telepath SMSC however provides functionality whereby it
can register MO messages whose text starts with a specific three character code. This feature
can be used by subscribers, whose phones do not allow them register MO messages. For more
information on MO registered messages, see Chapter 1 of the Mobile Network Interface
2.13 Message Completion
After each delivery attempt, tpkernel receives an acknowledgement to say whether a message
was delivered successfully. On receipt of this acknowledgement, certain fields of the message
in the disk database or FMS must be updated, for example, the message state and status. This
operation is carried out by Message Completer processes (tpcompleter).
2.13.1 Mode of Operation
The Message Completers need to know which messages are to be updated. This is done via
shared memory. Figure 2-7 illustrates the operation of the Message Completers.
RDBMS/
tpkernel FMS
1 inserts operation
into queue
tpcompleter
3
tpcompleter update
Shared Memory 2 messages
Database
tpcompleter
read the queues
tpcompleter
Figure 2-7: Message Completer Operation
1. tpkernel writes the required details of the message to a shared memory database for the
Message Completers to read.
2. On system startup, four Message Completers are created. They connect to the shared
memory database which holds four queues (one queue per Message Completer). Each
queue can hold sixteen messages that are awaiting processing.
Note: If you have a Premium message configuration, only one tpcompleter is required.
3. The Message Completers connect to the RDBMS or FMS in order to update the message.
Contact LogicaCMG Technical Support if further details are required.
Telepath SMSC Introduction Guide Message Validation and Routing
3. Message Validation and Routing
• Routing Management
• Address Translation
• *Prepaid Validation
• Retry Mechanism
• Global Title Addressing
• Home-Location Timezone
• MCE Notification
• MSC Address Storage
• Message Delivery to Dual Mode Phones
• Multi-Recipient Messages
• Delivery Mechanism Controls
Message Validation and Routing Telepath SMSC Introduction Guide
3.1 Routing Management
When an SM is routed to the Telepath SMSC, a certain amount of validation occurs on the
source and destination addresses. The validation criteria that are supported by Telepath SMSC
are outlined below.
Source and Destination address validation is explained in the sections below.
3.1.1 Source Address Validation
When an SM is sent from an SME, the source address is validated to prevent unauthorised use
of the short messaging service. The SM contains the TON, NPI and MSISDN/MSID of the
originator. This source address is compared with certain attributes of the Transmitter interface,
these are, the Type of Number (TON), Numbering Plan Indicator (NPI) and the Validation
Expression (VE). The Originator Validation field of the Interface record lets you specify a
Validation Expression and can be used to specify a range of MSISDNs/MSIDs that the process
will accept.
If you do not want the source address to be validated, then insert “trusted” (lower-case) into the
Originator Validation field of the Transmitter interface process using the
Control.Apps.Modify menu option in TPSMT. For more information, see the TPSMT User’s
Guide.
Note: Address Translation or Customer Validation will have an affect on Source Address
Validation.
Figure 3-1 illustrates how Source Address validation occurs.
TON=1
NPI =1 Rx
VE=1234 OR 1235
1 2
Tx tpkernel
Rx
SM
Rx
Figure 3-1: Source Address Validation
1. A SM is routed to the Telepath SMSC from the source address 1.1.123456 where the
address has a TON of 1, an NPI of 1 and a MSISDN/MSID prefix of 123456. The
Transmitter is configured with a TON = 1, an NPI = 1, and a VE= 1234* OR 1235* (which
means the process will accept all SMs originating from any numbers beginning with 1234
or 1235). It performs source address validation on the originating address and because the
TON, NPI and VE criteria are met, the SM is accepted.
2. The Transmitter forwards the SM onto tpkernel for subsequent delivery.
3.1.2 Destination Address Validation
When an SM is routed to the Telepath SMSC the destination address is checked to ensure it is
valid. This validation takes place at the Transmitter Interface. This ensures that an invalid SM
does not get stored on the system and is therefore not using system resources. The Transmitter
Interface looks at the destination address and checks if there is an appropriate Receiver
Interface to route the SM to its destination. To find the appropriate Receiver Interface, it checks
a Message Routing file. This file is described in section 3.1.2.1.
Figure 3-2 illustrates the Destination Address Validation process.
Destination
Address Rx
Validation
1 2 3
Tx tpkernel
SM Rx
Rx
Figure 3-2: Destination Address Validation
1. The Transmitter Interface receives an SM. It preforms Source Address Validation if so

configured.
2. It then performs Destination Address Validation: if there is a Receiver Interface on the
system that matches the SM delivery attributes, the SM is passed over to tpkernel.
3. tpkernel then forwards the SM onto the appropriate Receiver Interface.
3.1.2.1 Message Routing File
Message routing is the selection of the appropriate Receiver Interface for an SM. Telepath
SMSC provides functionality for multiple Receiver Interfaces enabling the loadsharing of
message delivery. Message routing is determined based on the following attributes:
• Service Centre ID (SC_ID)

• Teleservice (TS)
• Terminal Type (TT)

• Protocol ID (PID)
• Destination Type Of Number (TON)
• Destination Numbering Plan Indicator (NPI)
• Destination Address (If Address Translation is switched on, the translated destination
address).
For more detailed information on the Message Routing file, refer to Chapter 4 of the Telepath
SMSC Configuration Guide.
Figure 3-3 illustrates how the Transmitter Interface selects the appropriate Receiver Interface.
MNIF1_R
1 3
Tx tpkernel
SM SMPP_R
Message MNIF2_R
Routing
File
Figure 3-3: Message Routing Process
1. The Transmitter Interface receives an SM.

2. To find the appropriate Receiver Interface to route the SM to its destination, the
Transmitter looks up the Message Routing file and searches for a match based on the SM
attributes. For example, it can use the Teleservice ID to route Voicemail Receipts to the
SMPP_R Interface.
3.2 Address Translation
Address Translation provides the facility to translate SME source and destination addresses
from one format to another. This is done using Address Translation files. You can use the
system-wide default file, or you can create a new file for each interface. Each Address
Translation files maximum entry number is limited by system resources.
If you activate Address Translation on your Telepath SMSC, it is important to note that
translation is performed before any customer validation. Therefore validation is performed on
the post-translated address.
There are various ways to use the Address Translation feature, these are outlined below:
1. Translate the Address Format

Address translation is most typically used to translate National numbers to International
numbers. This translation is based on the MSID/MSISDN, TON and NPI. The main
advantage of this function is that subscribers no longer need to enter a complete
International number when they are sending an SM locally.
2. Black List Addresses

Address Translation provides the facility to Black List a number or a range of numbers
from sending or receiving SMs. This is an effective method of blocking messages being
sent to or from an unsupported subscriber.
3. * Black/White Listing
Address Translation also provides the facility to Black and White list a post-translated
number or a range of numbers. White Listing allows you to send messages to or from a
specified address. Black Listing disallow’s sending or receiving messages from a specified
address. It can be performed on both source and destination addresses.
Note: If Address Translation is off, the configurable parameter smsc_addr_trans_swt is set to

N, and White/Black listing is enabled, untranslated numbers are used.
4. Assign a Protocol Identifier (PID) to an Address

Some messages are sent with a specific PID already assigned. A PID can help in routing
the SM to a specific device, for example, a fax machine. It is possible to translate just the
MSID/MSISDN, TON and NPI of the address, leaving the PID unchanged. It is also
possible to assign a PID value to an address.
5. Address Extensions
If you have a large amount of messages going to the same destination and you want to
avoid long message queues on the system, this feature can be used. You translate the
address by adding extra digits to the end of it. This way you have a number of queues for
the same destination. The extra digits are stripped off the address by the ESME application.
Note: If the address length is validated (refer to section 4.2.2 on page 4-4), it is not advised
to use this feature as well.
Note: Address extensions are never used by the Mobile Network Interface.
6. Exact Address Matching
This feature lets you define specific criteria before Address Translation can take place. By
adding a Terminal Character ($) to the destination address entry, you are specifying that
an exact address match must be met before translation can take place. For example, if you
use a short-code, 061 for Customer Care, this number can be translated to the full
Customer Care address at the Telepath SMSC.
7. Wildcard Matching:
It is possible to enter wildcards in the Address Translation file. These wildcards indicate
that you don’t care what value is entered.
For more detailed information on Address Translation, refer to Chapter 4 of the Telepath SMSC
3.3 * Prepaid Validation
Prepaid Validation provides the facility to determine if a Short Message (SM) is prepaid and to
check that the sender or the intended reciever has sufficient credit to send or receive the SM.
The Tx determines that the message is prepaid. tpprepaidg interacts with an EBS to determine
the credit status of the customer.
For details on all the configurable parameters mentioned in the following sections, refer to
Appendix B of the Telepath SMSC Configuration Guide.
3.3.1 Successful Delivery
Figure 3-4 illustrates the processing of a prepaid SM through Telepath SMSC when delivery is
successful.
(short_msg table)
1) Regular Message
Validation
2) Message recognised Message Stored in DB with RDBMS
as a pre-paid SM. State of PP_Submission_TDP
Prepaid Profile is
created 3
7
SMs 4 5
Tx
tpprepaidg 6 EBS
tpkernel
Updates Database Routes Message

to Rx
9
10
Shared Memory
Database
Rx
Figure 3-4: Pre-paid Message routing through Telepath SMSC
1. When an SM is submitted to the Telepath SMSC, message validation is carried out as

described in section 3.1.1 and section 3.1.2.
2. Telepath SMSC identifies the SM as prepaid. There are six indications that a SM is pre-
paid. For more information on these indicators please refer to the Telepath SMSC
Configuration Guide. A profile of the configuration set for this prepaid SM is created at
this point. If the SM is not prepaid it is routed through the Telepath SMSC according to
the descriptions provided on section 2.2 on page 2-3, section 2.3 on page 2-4 and section
2.5 on page 2-7.
3. The pre-paid SM is inserted into the database with state PP_Submission_TDP.
4. The SM is sent to tpprepaidg by the Tx.
5. tpprepaidg sends the EBS a query to see if the message subscriber has enough credit to
allow delivery of the SM.
6. The EBS returns the required information to tpprepaidg.
7. If credit is available, tpprepaidg updates the database SM entry state to For_Delivery. If
the update state is For_Delivery tpprepaidg forwards the updated SM to tpkernel.
8. tpkernel updates the Shared Memory Database with details of the SM.
9. tpkernel sends the SM to the Rx for delivery to its destination.
3.3.2 Unsuccessful Delivery
A prepaid SM may be unsuccessful when:
• There is insufficient credit to send the SM

• An error occurs between Telepath SMSC and the External Billing System (EBS)
• An error occurs between Telepath SMSC and the receiving entity
Each of these cases are explored in the following sections.
3.3.2.1 Credit Unavailable
Figure 3-5 illustrates how a prepaid SM is treated when there is insufficient credit available to
complete its delivery.
(short_msg table)
Message Stored in DB with
State of PP_Submission_TDP
RDBMS
3
7
1-4 as in Figure 3-4 5
tpprepaidg EBS
9 6
Negative Response
8 Indicating No Credit
tpkernel
t States Database
10
Shared Memory
Database
Figure 3-5: No Credit Available
1-4) Are the same as described in section 3.3.1 on page 3-6.
5) tpprepaidg queries the EBS for the credit status of the subscriber submitting the SM.
6) The EBS returns a negative response indicating that there is in sufficient credit to send the
SM.
7) tpprepaidg updates the state of the SM in the database to For Delivery with a status of
PP_NoCredit.
8) The SM is then sent to tpkernel.
9) tpkernel checks the database to discover that the SM has a status of PP_NoCredit. tpkernel
then updates the state of the SM to Done and the status of the SM to Expired.
10) tpkernel deletes the SM from the Shared Memory Database.
3.3.3 Service Unavailable
There are three possible actions when an error occurs in validation. This error could arise from
a breakdown in communication between the PPG and the EBS. These different actions are
decided by the value you set on the smsc_pp_down_policy_ind. This parameter may be set to
1, 2 or 3. When the smsc_pp_down_policy_ind is set to:
1) No further SM processing is executed, and the SM is discarded from memory.
2) The SM is sent "free" of charge, but charged later.
3) tpkernel treats the SM as if it were expired.
Scenario One: Service Policy set to Discard
(short_msg table)
RDBMS
3
7
1-4 As in Figure 3-4 5
tpprepaidg EBS
8 6
Negative Response
or No Response
Figure 3-6: Service Policy Set to Discard
6) The EBS returns a negative response (except no credit) or no response. This raises a
PPG_QUERY_FAILED event when a query fails at the submission time. A
PPG_NO_NOTIFICATION_RESP is raised when there is no response to the notification
request after SM delivery. Both events are raised when the time configured by
smsc_pp_retry_interval_num multiplied by smsc_pp_max_EBS_requests_num seconds
expires. No further communication with the EBS is attempted for this SM query. The SM is
treated according to the value of the smsc_pp_down_policy_ind after a negative response. No
further action is taken when a PPG_NO_NOTIFICATION_RESP event is raised and the trigger
point is set for charging on successful delivery.
7) At this stage when the smsc_pp_down_policy_ind is set to 1, a PPG_DISCARD event is

raised. tpprepaidg updates the SM state to Done and the status to PP_Discard.
8) The SM is not forwarded to tpkernel. If you have enabled the pp_unavail_warn_swt, the
PPG sends an SM to the billable parties indicating that an error has occured.
Scenario Two: Service Down Policy Set to Free
(short_msg table)
RDBMS
3
7
tpprepaidg EBS
6
Negative Response
8 or No Response
tpkernel
Updates Database Routes Message

out to Rx
9 10
Shared Memory Rx
Database
Figure 3-7: Service Down Policy set to Free
6) The EBS returns a negative response (except no credit) or no response. This negative
response raises a PPG_QUERY_FAILED event when a query fails at the submission time. A
7) The SM is considered to be prepaid. Because the smsc_pp_down_policy_ind is set to 2, a

PPG_FREE event is raised. tpprepaidg updates the SM state to For Delivery.
8) The SM is forwarded to tpkernel.
9) tpkernel updates the Shared Memory Database.
10) The SM is routed to the Rx for transmission to its destination. Upon successful delivery,
tpkernel updates the database to state and status of Done and Delivered. tpprepaidg updates
this message to PPG_COMPLETION_TDP. This message is charged when tpprepaidg does a
full recovery on the database.
Scenario Three: Service Down Policy Set to Error
(short_msg table)
RDBMS
7
tpprepaidg EBS
11
9 6
8 Negative Response
or No Response
tpkernel
Updates Database
10
Shared Memory
Database
Figure 3-8: Service Down Policy set to Error
6) The EBS returns a negative response (not indicating no credit) or no response. This negative
response raises a PPG_QUERY_FAILED event when a query fails at the submission time. A
7) The SM is considered to not be prepaid. Because the smsc_pp_down_policy_ind is set to 3,

a PPG_DISCARD event is raised. tpprepaidg updates the SM state to For Delivery with a
status of PP_Unavail.
8) The SM is forwarded to tpkernel.
9) tpkernel checks the database to discover that the SM has a status of PP_Unavail. tpkernel
then updates the state of the SM to Done and the status of the SM to Expired.
10) tpkernel deletes the SM from the Shared Memory Database.
11) At this point if you have enabled the pp_unavail_warn_swt the PPG sends an SM to the
billable parties indicating that an error has occured.
3.3.4 Notification that Subscriber has been Overcharged
When the receiving entity is unavailable/unable to receive the SM, you can configure Telepath
SMSC to generate a notification indicating to the EBS that the subscriber has been overcharged
for an unsuccessful delivery. This is done if the following three criteria are met:
• SM is recognised as prepaid
• The per-interface parameter -pp_triggers_enabled_ind is set to 1 or 3, indicating that the
client was charged on submission , but the SM was not delivered
• The SM could not be delivered due to error, i.e. the status is one of Deleted, Expired,
Undeliverable, Invalid or Rejected
(short_msg table)
RDBMS
4
tpprepaidg EBS
2
4 cont.
Response
3 or No Response
tpkernel
Routes Message
to Rx
1
Rx SME
Figure 3-9: Subscriber Overcharged, SM Could Not be Delivered
1) SM routed out to SME which is either unavailable or unable to accept the SM.
2) The SM database record is updated by tpkernel with a state of DONE.
3) tpkernel sends the SM to tpprepaidg.
4) tpprepaidg sends the EBS a notification. If no response returns to the PPG before the time
configured by smsc_pp_retry_interval_num multiplied by smsc_pp_max_EBS_requests_num
expires, a PPG_NO_NOTIFICATION_RESP event is raised.
Note: Until this notification is successful the subscriber has been overcharged.
3.4 Scheduled Prepaid Messages
Prepaid SMs that are sheduled for delivery at some future date are treated as normal until the
message state changes from Scheduled to For Delivery. At this point the message is treated as
a prepaid SM.
3.5 Retry Mechanism
Telepath SMSC offers a flexible retry mechanism that manages the retrying of SMs. This is
useful if you attempt to deliver an SM to a handset that is deactivated or out of coverage. There
are a number of configurable options on the system that give you full control over the retry
mechanism and enable you to set up the optimum retry strategy.
Upon attempted delivery, tpkernel receives a General Acknowledgement (GACK) from the
Receiver Interface. This GACK specifies a result code for the delivery, a zero value indicates
successful delivery and a non-zero value indicates some error condition. How exactly the result
code is interpreted is specified by the retry profile and retry scheme definitions, but the resultant
behaviour can largely be categorised as one of two types:
• Permanent Error Conditions: where the SME error is considered non-recoverable. This
usually results in all the messages for that SME being marked Done.Undeliverable.
• Temporary Error conditions: where the SME error is considered transient. This usually
results in a retry scheme being adopted that will perform repeated periodic delivery
attempts (or retries) until the SME becomes available or until the scheme is exhausted.
Note: A third behaviour is provided for cases where only the current message is considered
undeliverable but other queued messages may be acceptable. In this case the retry
scheme can specify that only the ‘top’ message in the queue should be marked
Done.Rejected. The retry behaviour for Express messages differs, for more information
refer to section 2.5.2 on page 2-8.
Figure 3-10 illustrates an acknowledgement being sent back from the Recevier interface.
GACK (Error Code)

tpkernel
routes message
Rx
Figure 3-10: Delivery Attempt Acknowledgment
Message retries are handled using retry profiles. When a message fails to be delivered, an error
code is returned to indicate what went wrong and a retry profile maps this error code to a retry
scheme as shown in Figure 3-11 on page 3-15.
Figure 3-11: Retry Profile
For more information on each field refer to the TPSMT User’s Guide.
Based on the error code that is returned to tpkernel, retry is initiated for the SME. tpkernel
retrieves the retry profile from the shared memory database and maps the error code to a retry
scheme.
A retry scheme specifies up to eight retry levels. A sample retry scheme could be to retry the
message ten times at five minute intervals, then retry it twenty times at half-hour intervals, and
so on. If the last level of the scheme is reached without a successful delivery, then all messages
are set to Done Undeliverable. A scheme can also be defined to reject a single message using
the Reject option on the Action field of the Sme.Scheme.Add/Modify menu options in TPSMT.
When this action is taken it moves the top message for an SME to Done Rejected. Figure 3-12
on page 3-16 illustrates a sample retry scheme.
Figure 3-12: Retry Scheme
A number of retry profiles may exist in the system, with different profiles using different
schemes to handle the same error. A profile is identified by its ID, which is a unique number
assigned to a profile. If the Interface returns an error code to tpkernel which the retry profiles
do not manage, that is, there is no retry scheme assigned to the error code, then retry scheme 0
is used (Default retry scheme).
3.5.1 Retry Profiles
SMEs may have messages queued from several sources which may have different retry profiles.
Profiles are prioritised by ID, that is, Retry Profile 02 takes priority over Retry Profile 01 and
Retry Profile 01 has priority over Retry Profile 00, etc. The highest profile ID in the messages
queued for an SME is the one used to retry that SME.
The profile mechanism allows a fine degree of control over message delivery retries but care
must be taken as the performance of the system may be affected by how the retry profiles are
assigned and defined. The more frequently an attempt is made to deliver a previously
undelivered message, the more aware the customer is of the service. However, the less often an
attempt is made, then the less the load on the Telepath SMSC. This is an important
consideration for the running of the system, especially at peak times. Therefore a compromise
must be met between customer satisfaction and system efficiency.
A number of different Retry Profiles are provided. Each message is assigned one of these retry
profiles.
A retry profile consists of
• A retry scheme for each network error
• Retry schemes for local errors (i.e. no receiver, receiver socket full and maximum number
of expired messages in SME table)
Note: Previously, local errors had a single retry value. In this mechanism with a retry scheme
assigned to a local error, if that error persists, different retry intervals may be assigned.
For example, if the no receiver error persists for more than one day then all messages
against that SME with a message status of Undeliverable, can be assigned a delivery
status of Done.
3.5.2 Retry Schemes
A retry scheme associated with the occurrence of a specific error has the following properties:
• It may contain up to eight levels of retry instructions.

• A retry instruction has the following parameters:
- action (retry, override, reject)
- interval (length of time before the next retry attempt)
- repetition (number of times to use at this level)
New retry schemes and profiles may need to be defined if the network doesn’t handle certain
service elements such as SMS Alert Notifications. In some networks, the HLR can store the
address of the Telepath SMSCs that try to send a message to an SME while the subscriber is
absent from the network. It is possible to override this HLR facility by specifying an override
supplementary action on a per-level basis when defining new schemes. Up to one hundred retry
schemes can be defined.
Retry profiles and schemes are configured in the Sme.Profile and Sme.Scheme menu options
in TPSMT. For more information on configuring the profiles and schemes, refer to the TPSMT
User’s Guide.
3.5.3 Default Retry Profiles
In a retry profile, a scheme is associated with one or more errors. Different errors may require
different retry handling. To this end, a set of default schemes are defined. tpkernel initialises
the default retry schemes and profile at system startup. The Scheme ID is the number assigned
to the scheme, for example, retry_scheme_00 or retry_scheme_01.
retry_scheme_0 is used in the case that no recognised error occurs.
retry_profile_0 is the default profile for Standard messages.
retry_profile_20 is the default retry profile for Express messages.
Note: Retry Profile 0 cannot be modified.
The other retry schemes are mapped to the network errors supported by the Mobile Network
Interface. For more information on MN_IF errors, refer to the appropriate Mobile Network
Interface Configuration Guide.
3.5.4 Message Waiting Data Override
If, when the Mobile Network Interface queries the HLR for the location of an SME, the HLR
indicates that Message Waiting Data (MWD) is set, an SC-Alert (GSM) or SMSNOT (ANSI-
41) is generated when the SME becomes available. Therefore no delivery attempt should be
made. If, however, the message to be delivered is a Priority message, then a delivery attempt
will be made regardless of the setting of MWD.
3.6 Global Title Addressing
Routing messages from the Telepath SMSC to a destination address involves either point codes
(in which case the Maps and Links tables need to be configured in TPSMT) or Global Titles.
A Global Title is an address, for example the MSISDN/MSID which is keyed in by the user
when submitting an SM. This number does not contain the specific information needed to route
a message, and therefore it needs to be translated into the correct format. This process is known
as Global Title Translation.
Translating the Global Title involves deriving the Destination Point Code (DPC) and Sub-
System Number (SSN), which are then used to route the message over the SS7 network to its
destination. This translation takes place at the Signalling Transfer Point (STP). The advantage
is that a user can submit a message without knowing the explicit network address.
3.7 Home-Location Timezone
In large countries, a telephone network can span multiple time zones. Therefore, Telepath
SMSC can be located in a different time zone to some of the MSCs and HLRs. To cater for this
situation, the MN-IF can be configured to time stamp messages so that they have the same time
as either the visited MSC or the HLR of the mobile subscriber. In this way the time stamps in
the message are relevant to the message-recipient rather than Telepath SMSC or message-
originator. For a full description on configuration of the time zone, see Chapter 1 of the Mobile
Network Interface Configuration Guide.
3.8 MCE Notification
In GSM networks, a message is not accepted by a mobile station if there is no storage space
available on the SIM card. In this event, a Memory Capacity Exceeded (MCE) error is returned
to the Telepath SMSC from the network. The MCE Notification feature on the Telepath SMSC
can be used to send an indication to a designated ESME to alert the mobile subscriber that the
SIM card on the handset is full. For a full description on configuration of the MCE Notification,
see the Mobile Network Interface Configuration Guide and the SMPP Interface Configuration
Guide.
3.9 MSC Address Storage
When the Mobile Network Interface (MN-IF) makes a delivery attempt on a message, an
acknowledgement (GACK) is returned to tpkernel on the success or failure of the delivery
attempt. Each response may contain information on the MSC via which the delivery attempt
was made.
When the HLR sends an SMSNOT to the Telepath SMSC, MSC information may also be
included. Therefore, the MN-IF also returns this to tpkernel. In other words, if tpkernel
receives either an SMSNOT or a GACK, it stores the attached MSC data in shared memory. In
particular, it stores, the MSC address (PC-SSN and E164 format), the MSC address timestamp
and the Electronic Serial Number (ESN).
By storing this extra information in shared memory, tpkernel can forward the MSC address to
the MN-IF for alerted SMEs, which means that the MN-IF does not have to query the HLR for
routing information, if so configured.
Note: This feature is primarily used in ANSI-41 networks.
Figure 3-13 illustrates the MSC address storage process.
SMSNOT (MSC Information)

Tx 6
HLR
tpkernel
GACK (MSC Information)
4
5 1
Rx
2 3
Shared Memory
Database
+
MSC Information MSC
Figure 3-13: MSC Address Storage
1. tpkernel forwards a message to the Mobile Network Interface (Rx) to deliver.

2. The Rx forwards the message out to the appropriate MSC.
3. The delivery attempt fails, so the MSC sends a GACK back to the Rx.
4. The Rx returns this GACK to tpkernel. The MSC information is included in the
acknowledgement.
5. tpkernel updates the shared memory database and adds the extra MSC information to the
entry for that particular SME.
6. The HLR may send an SMSNOT for the SME, indicating they are back in coverage.
7. The Mobile Network interface (Tx) forwards this to tpkernel.
8. The MSC information is stored in the shared memory database and is therefore accessible
to the Rx. The Rx can make an immediate delivery attempt for that SME.
Note: The Mobile Network interface process can still query the HLR for routing information.
It is an optional feature.
If the MN-IF does NOT supply MSC address information to tpkernel, then nothing is stored.
However, if the MN-IF does supply the MSC destination address, tpkernel timestamps it. This
ensures that when it is forwarded to the MN-IF (for example, after an SMSNOT), the MN-IF
can decide if it is the most up to date information.
For more information on how to configure this feature on your system or how to remove
messages from storage, refer to Chapter 4 of the Telepath SMSC Configuration Guide.
3.10 Message Delivery to Dual Mode Phones
This feature can be used to deliver short messages to mobile networks where the users have
Dual-Mode handsets over which SMS termination is possible. A dual-mode phone is one that
can be used in different network technologies, for example, a phone can operate in both a ANSI-
41 TDMA network and a DCS1800 network. Successful delivery of the message depends on
the area of coverage that the subscriber is in.
Figure 3-14 illustrates how validation is performed for dual-mode handsets.
Customer Dual Mode Phone?--Yes

Record
5
Tx tpkernel
Rx
3
4
2
Message Routing
Shared Memory
File
Database
Figure 3-14: Dual-Mode Message Routing
1. When the message reaches the Telepath SMSC, the Transmitter Interface checks to see if
the message is destined for a Dual-Mode phone. This information is stored in the
Term_Type field of the Customer record. For more information, see Chapter 4 of the
Telepath SMSC Configuration Guide.
2. The Transmitter Interface checks the Message Routing file to find the appropriate
Receiver Interface to route the SM to. That is, it checks for the Primary Channel. For more
information on the Message Routing file, refer to Chapter 4 of the Telepath SMSC
3. The message is then forwarded to tpkernel
4. tpkernel stores the message in the shared memory database.
5. tpkernel then forwards the message out to the appropriate Receiver Interface.
Figure 3-15 on page 3-23 illustrates the channel selection process.
Message Delivery Attempt

PRIMARY CHANNEL
T
P
K Network Error
E
R Message Delivery Attempt
N Rx
E SECONDARY CHANNEL
L
Network Error
Message is marked for Retry

PRIMARY CHANNEL
Figure 3-15: Dual-Mode Message Delivery
If delivery of the message is unsuccessful due to incorrect access method being used (Primary
Channel), an immediate retry attempt is made on the alternative access method (Secondary
Channel). If the retry attempt using the Secondary Channel also fails, the message is marked
for retry according to the Network Error returned for the initial delivery attempt on the Primary
Channel. The retry attempt will be made using the Primary Channel.
Refer to Chapter 4 of the Telepath SMSC Configuration Guide for information on configuring
this feature.
3.11 Multi-Recipient Messages
A Multi-Recipient message is one which is submitted to a number of destinations. Multi-

Recipient messages are not treated as a single entity. The submission of a message to multiple
recipients is managed by a single interface primitive. The data supplied to that primitive is the
message contents and the destinations to which the message is to be delivered. The interface
primitive reproduces the message for each destination specified. These messages are managed
in the same manner as distribution list messages (see “Distribution Lists” on page 4-5), there is
a single message id for all the recipient messages.
The Replace operation can be applied to individual messages, and the Cancel operation can be
applied to both individual messages and lists. To Query the status of the Multi-Recipient
delivery, the head message must be queried. The head message is in a Done state when all
messages submitted are in a Done state, otherwise the message is For Delivery. Individual
messages to a given destination, can also be queried.
3.11.1 Maximum Number of Multi-Recipients
The maximum number of recipients, to whom a message may be submitted, is supplied by the
Interface to the Telepath SMSC as part of the message details. The maximum number of
recipients is restricted by the per-interface configuration item -max_multi_recpt.
If the maximum number of allowed recipients is not defined as part of an interface’s

configuration, a system default of 1,000 applies. The system wide value of 1000 overrides the
per-interface value. The Telepath SMSC validates the message details and rejects a message
submission request if this maximum is exceeded.
3.11.2 Trigger Detection Point (TDP)
Trigger Detection Points occour when the Telepath SMSC interacts with the EBS through
tpprepaidg during the processing of a prepaid SM. There are two Trigger Detection Points
(TDPs) for prepaid messages. One is when the state of an SM is updated to
PP_Submission_TDP, and the second is when the prepaid SM state is updated to
PP_Completion_TDP. Chapter 3 has details of when the first trigger exists and Chapter 3 for
details of the latter trigger. Refer to the interface configuration item for details on the -
_pp_triggers_enabled_ind per-interface parameter that controls these triggers, in Appendix C
of the Telepath SMSC Configuration Guide.
3.12 Delivery Mechanism Controls
The delivery mechanism is controlled by:
• The information/requests received by tpkernel (such as short message submission,

delivery notification from the mobile network etc.), hereafter referred to as Message
Delivery Triggers.
• The retry mechanism which prompts tpkernel to make a delivery attempt to an SME to
which delivery had previously failed.
These are discussed in the following sections.
3.12.1 Message Delivery Triggers
tpkernel’s actions are controlled by information or requests it receives from the Interfaces that
are bound to it, for example the SMPP Interface or the Mobile Network Interface. The
information or requests which affect the delivery mechanism are:
• Submission of a message, either Normal or Priority

• Delivery Attempt results:
• Successful Delivery
• Temporary Delivery Failure
• Permanent Delivery Failure
• Pseudo-Alerts
When a receiver binds to tpkernel, a Pseudo-Alert is sent to tpkernel to inform it that the
receiver has rebound and that messages can be retried. A delivery attempt is made on all
SMs that are to be routed through that interface.
• SC-Alerts/SMSNOTs from the HLR.
3.12.2 Mobile Registration Delay
When a phone is turned on, it initiates an update procedure to the HLR. The HLR then sends an
SMS Alert Notification to the Telepath SMSC to register the MS. However, there is a delay after
the MS has registered with the network, that is, the HLR and Telepath SMSC, before it is
capable of accepting SMs. For more information on how the Telepath SMSC handles this delay,
refer to Chapter 4 of the Telepath SMSC Configuration Guide.
Telepath SMSC Introduction Guide Provisioning Customers
4. Provisioning Customers
• Provisioning
• Customer Validation
• Distribution Lists
• Service Access Control
• User Groups
• Closed User Groups (CUGs)
Provisioning Customers Telepath SMSC Introduction Guide
4.1 Provisioning
Provisioning involves setting up and configuring the software required to activate a

telecommunications service for a customer. Once mobile subscribers are provisioned for SMS
on the HLR, they have full access to the service unless access is disabled on the Telepath
SMSC.
Provisioning on Telepath SMSC entails keeping different types of records in the Customer
database table. For example, System Administrators and Mobile Subscribers must be
provisioned for. It is possible to validate SMs sent or received to these subscribers by activating
customer validation.
For more information on provisioning System Administrators, see Chapter 2 of the Telepath
For more information on provisioning subscribers, refer to “Customer Validation” on page 4-2.
4.2 Customer Validation
When customer validation is switched on, the Telepath SMSC checks to see if the customer has
been provisioned. If you offer a range of value-added services with the Telepath SMSC,
customer validation is the method you can use to ensure only those customers that have
subscribed to the service can avail of it. You can provision all your customers on the Telepath
SMSC by adding customer records. These records are stored in the Customer table of the
database. You can view each record through the Provisioning.Customers.View menu option
in TPSMT. You can also provision customers through the use of the UserGroup functionality.
For more information on User Groups, refer to section 4.5 on page 4-5.
During the customer validation process, the system looks for details on both the source and
destination addresses, such as whether or not they can use the SM service. This information can
be taken from the customer record or from the UserGroup. The system can get information from
either of these sources in order to obtain an Effective Subscriber Record (ESR) to validate
against.
4.2.1 Validation Process
Figure 4-1 illustrates the process involved in Customer Validation.
Y Customer Y Validate
MSISDN Validation on? Record against
/MSID Exists? record
N N
Get UGID
from flat-file
(Default=0)
UG Administrator
record exists?
N Y
UG = 0 Use
it
Effective Subscriber Record
Figure 4-1: Customer Validation Process
• An SM is submitted to Telepath SMSC and if customer validation is switched on, a check

is made to see if the customer record exists in the database. If one exists then validation is
performed using the subscriber record.
• If the subscriber record does not exist, or customer validation is switched off, a User Group
Mapping is performed. This is achieved using a User Group identification file to define the
mapping between SME Address prefixes and User Group Identifiers (for more
information on the User Group Identification file, see Chapter 5 of the Telepath SMSC
Configuration Guide).
• If no User Group mapping exists then a default identifier of zero (User Group 0) is
assumed.
• As part of the User Group Mapping, an Administrator record for the particular User Group
is required. This record is a subscriber record that is used to represent the administrator for
each User Group supported in a particular Telepath SMSC deployment. The data in this
record is treated as default subscriber provisioning data for subscribers within the User
Group. For example, the Telepath subscriber record is the default administrator record for
User Group 0.
Where no provisioned administrator record is found then a hard-coded default record is
used.
• This information, either the individual subscriber record or the result of a User Group
Mapping, is then used to create an effective subscriber record that can be used for
validation purposes.
For more information on configuring customer validation on your system, refer to the Telepath
4.2.2 Extended Device Addressing
If a message is sent to a phone that has extended devices, such as a fax, e-mail or a Webserver,
each device is identified by a different number. These different identifiers are known as
extended device addresses. For example, if a phone has an extended device for a fax, the phone
number is identified by the following address 9.0.1234567890 (TON.NPI.MSISDN). The fax,
which is called by appending digits to the phone number, is identified by the number
9.0.12345678903 as displayed in Figure 4-2.
9.0.12345678903 FAX DEVICE
9.0.12345678904
E-MAIL DEVICE
9.0.1234567890
Figure 4-2: Extended Device Addressing
For more information on extended devices, refer to Chapter 5 of the Telepath SMSC
4.3 Distribution Lists
A Distribution List (DL) can be used to submit the same message to a number of recipients. DLs
can be system-wide and available to all subscribers or User Group specific. User Group DLs
can be generated using the SMPP Provisioning process (Short Message Peer-to-Peer
Provisioning). SMPP Provisioning provides an interface for External Short Message Entities
(ESMEs) to provision individual subscribers and distribution lists in Telepath SMSC. For more
information on Provisioning DLs using SMPP Provisioing, refer to the SMPP Provisioning
Note: To submit a message to a System DL, the destination TON must be set to Abbreviated
and the destination NPI must be set to Unknown.
4.4 Service Access Control
Telepath SMSC supports a range of application services, which can be provided selectively to
individual users or groups of users, within the subscriber base. The actual services offered by a
particular Telepath SMSC deployment differ on an operator-by-operator basis. Telepath SMSC
supports the feature of “Service Access Control” to allow you to define the particular services
and to define the availability of these services to users of the Telepath SMSC.
Service Access Control allows for up to 32 independent application services to be defined by

the Administrator, each of which must be assigned a numeric value in the range [0..31]. Service
Access Control is applied based on the interface used for message submission.
Refer to Chapter 5 of the Telepath SMSC Configuration Guide for information on how to use
this feature.
4.5 User Groups
Telepath SMSC provides messaging functionality to groups of SMS subscribers. These

subscribers may work for a corporate customer, or may belong to a Service Provider (for
example, a Voice Mail service provider). In Telepath SMSC, these groupings are referred to as
User Groups. Message transactions from a User Group member may be received over any of
the interfaces supported by Telepath SMSC (TAP, UCP, Mobile Network Interface) and
messages may be delivered via any of the interfaces supported by Telepath SMSC (SMPP,
Mobile Network Interface).
The use of messaging resources can be controlled and monitored on a per-User Group basis.
The amount of messaging resources used by a User Group is defined by the System
Administrator. These are defined when you create a User Group record through TPSMT. For
more information, refer to the TPSMT User’s Guide. If a User Group exceeds its maximum
allocation of any resource it is throttled, which means the User Group is denied access to
message resources for a period of time. The task of resource management is to allocate
resources to a User Group and to throttle a User Group if it exceeds its resource allocation.
4.5.1 Messaging Resources
Messaging resources are required to provide the messaging functionality and are of two types:
• Message Operation Processing

• Storage Capacity
4.5.1.1 Message Operation Processing
Message Operation Processing (MOP) is the handling of messaging operations such as a

message submission or a delivery attempt. Telepath SMSC defines a unit called a MOP which
is a measure of the processing cost of performing a messaging operation. A User Group is
allocated a portion of the MOP units of the system and the maximum number of MOP units
available per hour is defined for each User Group. Message operations include:
• message submission
• message replace
• message cancellation
• message status query
• message retry
• message delivery
• receipt generation
MOPs are a transient resource, in other words resource usage in one time period has no impact
on the amount of available resources in the next time period. Therefore unused MOPs cannot
be carried over from one time period to the next.
4.5.1.2 Storage Capacity
Storage capacity is the number of messages that can be held in the system whether they are
messages awaiting delivery or messages which have reached a Done state and are available for
query. The maximum number of messages that may be stored is defined for each User Group.
Storage is a permanent resource, that is, storage must be explicitly released by purging
messages from the database (Classic messaging only). Storage allocation is performed nightly,
following the message database purge. The storage used by each User Group is calculated and
the unused space is made available for the next time period.
In the case of Premium messaging, self-purging occurs.
4.5.2 Allocation
There are two allocations to be made to a User Group as mentioned above; MOP and Storage.
The allocations are defined by the System Administrator through the TPSMT interface. The
sum of the resource allocations should not exceed the total resource capacity of the Telepath
SMSC. The allocations are then assigned to each User Group for a defined time period. The
MOP time period is on a per hour basis, and the storage time period is on a daily basis. For more
information on allocating resources to a User Group, refer to the TPSMT User’s Guide.
4.5.3 Throttling
If a User Group exceeds its allocation of either of its resources it is throttled, which lasts until
the allocation’s time period has elapsed (one hour for MOPs and one day for storage). All
messaging carried out is deducted from the MOP allocation of the source User Group of the
message. The MOP throttle takes precedence over the storage throttle, so if there is a MOP
throttle in place, then the User Group receives no service, even if there is spare capacity in the
storage allocation. However, if there is a storage throttle in place, the User Group will continue
to receive service until the MOP allocation is used up, although no new message submission is
possible, as there is no space available to store the message.
In the case of Premium messages, storage throttling is not relevant because Premium messages
are self-purged. For more information, refer to Chapter 4 of the Telepath SMSC Maintenance
Guide.
4.5.3.1 MOP Throttle
MOP allocations apply for a one hour period. At the end of this period tpkernel resets MOP
throttles which have been imposed on the User Groups, and each User Group is assigned an
allocation as specified in the User Group definition in TPSMT.
4.5.3.2 Storage Throttle
Storage allocations apply for a one day period. If a User Group has a storage throttle imposed,
it can only be removed if storage is freed up when the database is purged by tppurge.
• Each User Group defines the length of time Done messages for that User Group are
retained in the database. This is known as the ‘Purge Time’ of a message and it is
associated with the message at submission.
• When a message reaches a Done state the current date and time are added to the Purge
Time of the message to give the time after which the message can be removed from the
database.
• The storage allocation is re-calculated after the database purge and the number of
messages stored for each User Group is counted by tppurge.
• This count is subtracted from the maximum storage allocation of the User Group, giving
the storage allocation for the next day.
Note: The per-User Group control of purging does not apply to Premium messages.
Notification of Resource Throttling
When a resource usage threshold, which has been defined by the System Administrator, is
reached, an event is logged and the Status field on the User Group command form in TPSMT
is set to Throttled. The Status is reset when the resource usage is below the threshold value.
4.5.4 User Group Retry
Retry profiles can be assigned to a User Group and priority can be given to delivery of messages
from a User Group by giving the User Group an aggressive retry profile. The retry profile of
highest priority is selected from all the messages queued for an SME. The retries are charged
to the source User Group of the message whose retry profile is being used.
Note: The retry profile used affects the consumption of MOP units. This should be taken into
account when allocating User Group resources.
For more information on how to configure User Groups, refer to the Chapter 5 of the Telepath
4.6 Closed User Groups (CUGs)
You can create a Closed User Group (CUG) to limit the service range of a group of customers.
A CUG is a subset of users who are limited to sending messages only to members within the
group, but receiving messages either from members of the group or outside. For example,
CUGs may include company departments such as accounting, administration and purchasing.
The Telepath SMSC is aware of the group boundaries and does not allow any message
deliveries out of the group if outside numbers are attempted.
Figure 4-3 illustrates the functionality of CUGs.
CUG
Send messages to Cannot receive

any member of the any messages
CUG from any member
of the CUG
Members of a CUG can send and

receive messages to and from each
other, but they cannot send
messages outside of the group
Figure 4-3: Closed User Groups
You can add, modify and delete CUGs using TPSMT or TPPROCUS. Refer to the TPSMT
User’s Guide and the PROCUS User’s Guide for further information.
Telepath SMSC Introduction Guide Platform Management
5. Platform Management
• Capacity Licence Monitor

• Network Cluster Member Formats
• Network Specific Address Formats Definitions
• Network Error Code Definitions
Platform Management Telepath SMSC Introduction Guide
5.1 Capacity Licence Monitor
Telepath SMSC systems are licensed on a capacity basis. This means that a system is assigned
a licence to deliver a defined number of short messages during the busiest hour of the day. This
licence is known as the Capacity Licence, and is measured in terms of the Busiest Hour Short
Message Delivery Attempts (BHSMDA). BHSMDA is the cumulative number of Forward
Short Message (FSM) or Short Message Delivery Point-to-Point (SMDPP) transactions
between the Telepath SMSC and one or more MSCs.
Note: FSM refers to the Forward Short Message transaction from ETSI GSM 09.02 standard.
In ANSI-41D, FSM = SMDPP (Short Message Delivery Peer to Peer)
The Capacity Licence Monitor is a tool that provides Telepath SMSC system administrators
and Logica with information to help monitor system use in comparison to the Capacity Licence
for the system in question. It is based on a Capacity Licence Key which is loaded at system
startup. For a full description of how the Capacity Licence Monitor operates, see Chapter 1 of
the Telepath SMSC Maintenance Guide.
5.2 Network Cluster Member Formats
The system administrator can choose the format of the point code on the Telepath SMSC. The
point code can be displayed in either network-cluster-member or decimal format depending on
the network. You specify the point code format by modifying the configurable parameter
smsc_point_code_mde. It can be set to any of the following values:
• 0 - Standard decimal Point

• 1 - GSM Network-Cluster-Member (14 bit, maximum threshold 7-255-7)
• 2 - ANSI-41 Network-Cluster-Member (24 bit, maximum threshold 255-255-255)
Refer to Appendix B of the Telepath SMSC Configuration Guide for information on
smsc_point_code_mde.
5.3 Network Specific Address Formats Definitions
The Type Of Number (TON) and Numbering Plan Indicator (NPI) definitions are
preconfigured appropriately for the specific deployment during installation. They are based on
the underlying PLMN type. The list of definitions can be viewed using the TPSMT
Control.Codes.List option as shown in the TPSMT User’s Guide.
Note: These definitions should not be modified without prior consultation with LogicaCMG
Technical Support.
Table 5-1 provides the numeric and abbreviated values of valid TONs and NPIs.
Abbreviated Abbreviated
Valid TONs Valid NPIs
Value Value
0 Unknown unk 0 Unknown unk

1 International int 1 E164 e16
2 National nat 3 X121 x12
3 Network ntw 4 Telex tlx
4 Abbreviated abv 8 National nat
5 Alphanumeric alp 9 Private prv
6 Reserved 1 rv1 10 ERMES erm
7 Reserved 2 rv2
Table 5-1: TON and NPI Address Translation File Numeric Values
5.4 Network Error Code Definitions
System error codes for message delivery failures are dependent on the particular network-
interfaces deployed. The Network Error Codes relevant to a specific deployment are configured
appropriately during installation. The list of definitions can be viewed using the TPSMT
Control.Codes.List option as shown in the TPSMT User’s Guide.
Note: These definitions should not be modified without prior consultation with LogicaCMG
Technical Support.
Telepath SMSC Introduction Guide Billing Customers
6. Billing Customers
• Telepath SMSC Billing

• Billing Processes
• Billing File Formats
• File Naming Convention
Billing Customers Telepath SMSC Introduction Guide
6.1 Telepath SMSC Billing
The Billing function is the core component used in the Telepath SMSC to generate records for
short messages. Billing information is generated based on real-time information. Call Detail
Records (CDRs) are generated as soon as a message reaches a final state.
CDRs contain specific user-defined information relating to the delivery of an SM. An

individual CDR is generated for each SM and they are stored in a Billing file. CDRs are used
in the billing of subscribers and also for statistical analysis. Each CDR contains a detailed
account of the SM, for example, who sent the SM, where is it going to, how many delivery
attempts were made, and so on.
It is possible to control CDR production on a per-Interface basis also. If you do not want to
charge a subscriber for SM submission over a particular interface then you can turn off the CDR
functionality. The benefit of this feature is that it lets you finely tune the Telepath SMSC. For
example, if you have subscribers that pay for specific services on a monthly basis then you may
not want to charge them on a per-message basis.
The billing process, tpspooler, is responsible for generating Call Detail Records (CDRs) in
Tag-Length-Value (TLV) format. Once they have been placed into a billing file they are
converted from TLV format to the format of your choice. For more information on Billing File
formats, see Appendix D of the Telepath SMSC Configuration Guide.
6.2 Billing Processes
The operation of the billing processes is described in Figure 6-1.
- tags.xml file
t
tpkernel
definition of TLV record in TLV file 1
5
sends billable messages
2
tpspooler
tpspooler
Database
Database Updates cdrstat table
4 3 CDRs generated and stored

CDRs transferred
when closed
DIR_INPUT CDR_DIR
Figure 6-1: Communication of Billing Processes (Part 1)
1. tpkernel forwards all billable messages to tpspooler. Call Detail Records are not
generated for non-billable messages, for example, test messages.
2. tpspooler updates the cdrstat table in the database. This table contains information on all
the billing files and can be viewed through TPSMT. For more information on TPSMT, see
the TPSMT User’s Guide.
3. tpspooler creates a CDR for each message and puts it into a billing file in the CDR_DIR,
by default this is set to /cdr. Each billing file is closed after a five minute interval or if the
cdr_max_records_size is exceeded.
4. From there the billing files are transferred to the DIR_INPUT directory. In order for this
to happen, you must set the configurable parameter cdr_transfer_cmd to the same value as
DIR_INPUT, which is set to /cdr/closed.
5. tpspooler reads the format of the TLV record for every messages in this file. Without
reading this file tpspooler cannot run correctly. The location of this file is defined by the
configurable parameter cdr_def_file_of_tlv.For further information on this configurable
parameter please refer to Appendix B of the Configuration Guide.
Note: Subdirectories off /cdr/closed are not supported.
Figure 6-2 illustrates how billing functions.
DIR_INPUT
cdrp_config.cfg
1 Reads file for header/trailer

tpcdrpostpp information
3 4
DIR_OUTPUT DIR_BACKUP
Figure 6-2: Communication of Billing Processes (Part 2)
1. tpcdrpostpp reads the configuration file cdrpp_config.cfg for information on what post
processing it must perform on each CDR. Information includes, the billing file format, the
header and trailer and the transfer location. For an example of the configuration file, refer
to the Telepath SMSC Configuration Guide.
2. It then takes the CDRs from DIR_INPUT which are in TLV format and converts them to
the format specified in the configuration file.
3. tpcdrpostpp places the processed files in the location specified by DIR_OUTPUT.
4. Finally, tpcdrpostpp moves the original TLV-format file from DIR_INPUT to the
location specified by DIR_BACKUP.
6.3 Billing File Formats
A billing file can have one of five predefined formats, or it can have a customised format. The
appropriate format is assigned at installation time by setting the FORMAT field in the
cdrpp_config.cfg file. This format is system dependent and does not need to be modified. The
possible values for the FORMAT field are format1, format2, format3, format4, format5, and
custom. Each of the formats are individually described in Appendix D of the Telepath SMSC
If the value of the parameter FORMAT field equals custom, then you must list the tags you want
to include in your billing file. If tpcdrpostpp unsuccessfully retrieves the value of this
parameter then it sets the billing file format to the predefined format, format2.
See Appendix D of the Telepath SMSC Configuration Guide for a full list of custom fields.
6.4 * Pre-Paid Billing
Billing for a pre-paid SM as stated previously is controlled by an External Billing System

(EBS). There are three methods of requesting billing from an EBS for pre-paid SMs. You can
configure your system using the -pp_triggers_enabled_ind per-interface configurable
parameter to request billing on:
• Submission of the pre-paid SM

• Successful delivery of the pre-paid SM
• Submission and successful delivery of the pre-paid SM
Refer to the Telepath SMSC Configuration Guide for more details.
6.5 File Naming Convention
The name of a billing file is determined by the date and time that it was opened. The format
used for the file naming is as follows:
<Month><Day>.<Time Zone><Hour><Minute><Second>.00
For example, if a billing file was opened on February 1st, at 4.30 pm., then the following name
is used for this file:
0102.BST163000.00
Note: The file naming uses 24 hour clock timing.
6.6 *Real Time Billing
Real Time Billing allows TLV billing data generated for Done messages to be spooled to a
separate Billing Management System (BMS) application in real time. TLV data is sent to the
BMS by a process called rtspooler which is spawned from tpspooler. For more information on
Real Time Billing refer to section 2.6“*Real Time Billing” on page 2-10.
Telepath SMSC Introduction Guide Monitoring the System
7. Monitoring the System
• Monitoring Telepath SMSC Processes

• Monitoring the UNIX System
Monitoring the System Telepath SMSC Introduction Guide
7.1 Monitoring the System
As part of system monitoring there are specific areas on the Telepath SMSC platform that are
monitored. This ensures redundancy in case of process failure and risk management for third-
party applications, such as the Unix operating system.
System monitoring can be divided into two areas: Telepath SMSC monitoring and Resource
monitoring. These areas are dealt with separately in Chapters 1 and 2 of the Telepath SMSC
Maintenance Guide.
Telepath SMSC Introduction Guide Monitoring the System
7.2 Monitoring Telepath SMSC Processes
The Telepath SMSC has a process monitoring function aimed at ensuring that the system is
resilient to process failures. That is, it monitors the running Telepath SMSC processes, and
provides a recovery mechanism in the case of a process failure. A standalone process,
tpmonitor, periodically checks the state of the Telepath SMSC processes and, depending on
their classification, makes decisions on necessary recovery actions. The processes can be
classified as follows:
• Core processes
• Mobile Network Interfaces
• Interworking Interfaces
• User Interfaces
As part of monitoring Telepath SMSC, it is also necessary to gather information on messaging
performance. This can be done by examining the statistics in the Event log and the Statistics
log. The statistics that are generated can also be viewed through the Distributed Management
Metrics (DMM) module 1. This is a java-based GUI that lets you gather statistics on your
system and view them in graphical format. The module is designed to provide you with the data
needed for strategic business decisions based on customer usage of specific services. For more
information on the DMM, refer to the DMM User’s Guide.
Message Auditing is another feature on the system that provides you with the means to see in
more detail specific transactions. For example, if you want to find out information on message
submissions or on message deliveries, or if you require more in-depth information on how
messages are processed, you can select different levels of auditing.
For further information on monitoring Telepath SMSC, refer to Chapter 1 of the Telepath
SMSC Maintenance Guide.
1. The DMM is an add-on module, for more information contact your LogicaCMG Technical
Support Engineer.
Monitoring the System Telepath SMSC Introduction Guide
7.3 Monitoring the UNIX System
The Telepath SMSC uses proprietary software and hardware as described in Chapter 1, Context
of Telepath SMSC. The System Administrator must monitor the system every day to ensure it
is providing optimum performance. There are a number of utilities available to monitor system
activity and to monitor system resources.
The Resource Monitoring Tool, which is provided as part of the standard configuration, is
responsible for checking CPU usage, filesystems, SS7 and X.25. It records the state of each
resource based on defined thresholds and logs an event if a threshold is breached. Based on this
information, it is possible to configure your system to generate an Alarm when this occurs.
You can also manually check some of these resources using specific UNIX commands. For
example, to retrieve information on disk partitions, the bdf command is used, and the sar
command generates System Activity Reports.
The sar command (System Activity Report) is run every day to obtain statistical information
on the system, for example, processor and memory utilisation, buffer cache activity.
The bdf command is also run every day to monitor disk utilisation. It provides information on
the different partitions on disk. For each partition on the system, this command reports:
• the total number of kilobytes

• the number of kilobytes used
• the number of kilobytes available
• the percentage of used disk blocks on that partition.
For further information on resource monitoring, refer to Chapter 2 of the Telepath SMSC
Maintenance Guide.
Telepath SMSC Introduction Guide Event and Alarm Management
8. Event and Alarm Management
• Events
• Event Types
• Event Filtering
• Event Actions
• Event Classes
• Event Logging Thresholds
• Event Log Files
Event and Alarm Management Telepath SMSC Introduction Guide
8.1 Events
Telepath SMSC is supported by a comprehensive set of alarms and events, which monitor not
only Telepath SMSC, but also the underlying hardware and software. The events provide
information on what is happening on the system, and alarms can be configured to occur when
something unusual happens on the system. Alarms and events can be written to a log file, they
can be sent to a port on your network management system, they can be written to a Management
Information Base (MIB) or to an e-mail address. You can define filters and acceptable
thresholds for each event and gather statistical information from the event logs.
Not all events may be relevant to your system, therefore it is possible to filter these events so
that they are ignored. Also, you may wish to assign a certain action to an event, for example, if
a specific event occurs you may want to run a maintenance script.
For further information on event filtering and how to configure it on your system, refer to
Chapter 7 of the Telepath SMSC Configuration Guide.
Telepath SMSC supports the Simple Network Management Protocol (SNMP). SNMP is an
open standard protocol that defines a range of transactions that enable SNMP Manager
applications, such as HP OpenView, to control and monitor entities within your network,
including Telepath SMSC. SNMP is widely used to support fault, performance, and
configuration management.
8.2 Event Types
Each component on the Telepath SMSC system has event types associated with it, an error
event and an informational event. Every event follows a standard naming convention. Refer to
“Events and Statistics” in Appendix E of the Telepath SMSC Configuration Guide for a list of
these event types and the associated codes. The system component is identified by the prefix of
the event name, and the suffix is _ERROR, _INFO, or _TRAP identifying an error or an
informational event. However, in the case of the SMK component, it may also generate a
statistics generation request event, SMK_STAT, which uses a STAT suffix.
All of the event types are stored in the etype table in the database. Each event type stored has
the following attributes:
Event Name: This is the textual name of the event, for example,
MNAIM_ERROR or DB_INFO.
Event: This is a unique ID for each error/information/warning
events.
Class: This is a classification for the event, for example, it can
be informational, warning, error, or fatal. For more
information, refer to section 8.5 on page 8-6.
Lower Threshold: This field lets you define a threshold for the number of
times an event much occur within a given period before
any action is taken. For more information, refer to sec-
tion 8.6 on page 8-7.
Interval: Used in association with the Lower Threshold. Lets you
define the interval in seconds before any action is taken
on that event. For more information, refer to section 8.6
on page 8-7.
NM Class: This field indicates whether or not the event should be
logged to a Network Management System through a
previously defined communication link.
Action: This defines the action to be taken when an event
occurs. For more information, refer to section 8.4 on
page 8-5.
Description: This is the textual description of the event, for example,
“Database Error”.
8.3 Event Filtering
For each event type there is an associated set of error codes (see Appendix E of the Telepath
SMSC Configuration Guide for a complete list). It is the combination of event type and error
code that defines a unique Telepath SMSC event. You can filter events based on event type and
error code. Filtering events based on event type means assigning an action to the event type.
Filtering events based on the error code means that no processing is carried out on that
particular event. Filtering by error code is a way of reducing the number of events being logged
to the event log and also a way of reducing the number of alarms generated on your system.
For more detailed information on Event Filtering, refer to Chapter 7 of the Telepath SMSC
8.4 Event Actions
Every Event has a configurable Action field associated with it, to determine what the system
does when an Event has occurred. This field can be set using the Events.Types.Modify
command in TPSMT. There are three possible values for this field, as described below:
• Ignore
Events with Action set to Ignore are not logged.
• Log
Events with Action set to Log are logged to the two Event logs, elog_fle and
elog_printer_fle only. This is the most common action to take. For a sample event log,
refer to section 8.7 on page 8-8.
• LogToDb
Events with Action set to LogToDb are logged to the two Event logs, elog_fle and
elog_printer_fle, and in addition to the elog table in the database.
• Message
Events with Action set to Message are logged to the two Event logs, elog_fle and
elog_printer_fle, and in addition an e-mail is sent to the user defined in the configurable
parameter elog_mail_cmd to indicate that this Event has occurred. If this parameter does
not exist the message is mailed to the user telepath. It is assumed that the system
administrator is the user telepath.
8.5 Event Classes
Events can be assigned one of four different classes. These classes are: Information, Warning,
Error, and Fatal. The user may wish to configure the classes for the Events, which can be done
using the Events.Types.Modify command in TPSMT. Table 8-1 provides a possible
description for each Event class. It is important to remember that these classes are for the user’s
use only, and do not affect the running of the system. You assign one of the classes to the event
type according to the severity you deem appropriate on your system.
Event Class Description
Information These Events gather information about normal operation. They do not
require any action to be taken.
Warning Events in this class do not affect the operation of the system. They
happen regularly and it is left to the discretion of the operator whether
they require attention or not.
Error Events in this class do require attention. It means that something has
gone wrong which is affecting the performance or operation of
Telepath SMSC.
Fatal An Event which occurs with this class is fatal and results in the
Telepath SMSC no longer operating correctly. Contact Technical
Support.
Table 8-1: Event Classes
8.6 Event Logging Thresholds
Not every occurrence of an Event must be logged. Each Event in the Event Type table has an
interval and a lwr_threshold value associated with it. The interval can be set to a number of
seconds and the lower threshold can be set to the number of times a particular Event must occur
before it is logged.
For example, for Event type SMS_ERROR, if the interval field = 60 and the lwr_threshold =
4, this results in the following:
When an SMS_ERROR Event has occurred 4 or more times in 60 seconds the Event will
be logged, i.e., the first three times an SMS_ERROR Event occurs in a one minute period,
the occurrence is not logged. The counter counting the number of these Events is reset
every 60 seconds.
All Event types are initially set up with an interval of 0 and a lower threshold of 0 causing all
occurrences of an Event to be logged. Depending on system requirements, these values can be
modified using TPSMT.
8.7 Event Log Files
Log files keep a record of each event (if the Action is set to Log) as it occurs in the system. The
names of these files are determined by the elog_fle and elog_printer_fle parameters. Events are
written simultaneously to these two files, referred to as Event logs, therefore they are identical.
The system administrator monitors the events which occur and takes the relevant action for that
Event (which in some cases is no action at all). Event logs must be monitored daily to ensure
there are no serious problems occurring within the system.
The format of the event log is described in the following table:
Variable Sample Value Description

<Process> tpsmt Process which generated the Event.
<Event Type> SMK_INFO Event name generated
<Time> 1503.125633 Date and Time the event was generated.
<Class> I Event class, in this case Information.
<SMSC Id> Telepath Id of the Telepath SMSC. Set by the
configurable parameter nms_smsc_id_str.
<Error Code> 434 Error code used for statistics purposes
<Description> Process has disconnected from Brief textual description of the Event
the database
<Filename> didb.c File that the Event was generated from.
<Line Number> 225 Line number in that file.
<Process Id> 8784 Uniquely identifies the process.
<Additional telepath_smf Provides additional information on this
Info.> instance of the Event.
Table 8-2: Sample Event Log Record
Using the above example, the following indicates the actual format of an Event log record as it
appears in the Event log file:
tpsmt :SMK_INFO :1503.125633:I:Telepath :434:Process has

disconnected from the Database:didb.c,225,8784:telepath_smf
Telepath SMSC Introduction Guide Amendments
Appendix A: Amendments
Telepath SMSC Release 2700 has been upgraded from Release 2650. The updated
documentation includes new features and functionality, plus corrected defects and general
enhancements. These are referenced in the following tables.
Location Description
Chapter 1: Context of New descriptions added for DAP, RAP and DMM.
Telepath SMSC
Chapter 2: Message Added in new section on Premium Messaging.
Management
Chapter 2: Message Added in new section on Express Messaging.

Management
Chapter 2: Message Added in new section on Classis Messaging.

Management
Chapter 3: Message Added in new section on Source and Destination Address
Validation and Routing Validation.
Chapter 3: Message Added in updates to Address Translation feature.

Validation and Routing
Chapter 3: Message Added in new section on MSC Address Caching.

Validation and Routing
Chapter 2: Message Added in new section on Short Message Delivery to Dual Mode
Validation and Routing Phones.
Chapter 4: Customer Added in information about Extended Device Addressing.

Provisioning
Chapter 4: Customer Updated COS Codes for Service Access Control.

Provisioning
Table A-1: Corrected Documentation Defects and Enhancements for UD2
Location Description Reference
Section 1.3 and Added Customer Care feature - Customer Care

Section 2.4 Server and Customer Care for Premium Messaging
(tpccp)
Chapter 2 All references to tppurge/tpunpurge removed and all DOCDOO20465

references to the deadshort_msg table. tppurge in
Figure 2-3 replaced by “backup process”.
Table A-2: Corrected Document Defects and Enhancements for UD3 and UD4
SMS-2700-INTRO-xxxx-UD10 A-1
Amendments Telepath SMSC Introduction Guide
Chapter 2 The ftp process has changed in that in does not now DOCDOO19409
generate a .ccp file on the Telepath platform when a
TLV file has been successfully transferred, instead
it moves the file on the Telepath platform form the
directory specified by the ccp_cdr_dir cparam to the
directory specified by the cdr_dir cparam with /
closed tagged onto the end.
Glossary Removed “Control” from before Message. View. in DOCDOO14403

the PID description. Changed PID to PID (GSM)
and changed Pid to PID.
Section 6.2 Added the sentence “subsidectories off /cdr/closed TTSMS08399
are not supported.
Table A-2: Corrected Document Defects and Enhancements for UD3 and UD4
Section 1.4.12 Prepaid and the EBS.
Section 6.4 Prepaid Billing.
Section 2.7 Includes new states and status relating to prepaid messaging.
Section 2.9 Prepaid Message Recognition.
Section 2.10.1 How to set billing for Prepaid.
Section 2.10.1.1 Details on the prepaid description or profile.
Section 3.3 New sections describing Prapaid Validation.
Section 3.4 Scheduled Prepaid Messages.
Section 3.11.2 Section added on trigger detection points.
Table A-3: Document Enhancements for UD5
Section 3.2 Added a new section on Black/White Listing (ud6)
Chapter 2 Moved the following sections from the Introduction Guide to the
Configuration Guide:
Message Billing
Setting Billing for Prepaid Messages
Prepaid Profiles
Table A-4: Document Enhancements for UD6 & UD7
A-2 SMS-2700-INTRO-xxxx-UD10
Telepath SMSC Introduction Guide Amendments
Figure 6-1 Added -tags.xml to figure, with the comment DOCDOO26838

“definition of TLV record in TLV file”.
Section 6.2 Billing Added additional point, number 5. DOCDOO26838

Processes
Step 1, page 6-4 replaced cdrpp_config.dat with cdrp_config.cfg DOCDOO26838
Figure 6-2, page 6-4 changed name cdrpp_config.dat to cdrp_config.cfg DOCDOO26838
Section 1.3 Changed the number of days messages are stored for
in the Customer Care Server from 6 to 7.
Section 2.4.1 & Removed these sections as there are dulpicate

Section 2.4.2 sections in the Telepath Maintenance Guide.
Table A-5: Document Enhancements for UD8
Section 2.6 Added 3 sections on Real Time Billing including

how to start and stop it.
Table A-6: Document Enhancements for UD9-FOA
Entire Document Removed all references to tpdbsrv and tpwatcher. Mod 1
Chapter 2: Message Rewrote all sections to include diagrams. Mod 2

Management
Chapter 7: System Added new chapter to differentiate between Mod 3

Monitoring monitoring Telepath SMSC and monitoring system
resources.
Chapter 5: Platform Added in new chapter to include information on Mod 4

Management Capacity Licence Monitor, Network Error Codes
etc.
Chapter 3 Amended section 3.2 point 5 SMSD0028539
SMS-2700-INTRO-xxxx-UD10 A-3
Amendments Telepath SMSC Introduction Guide
A-4 SMS-2700-INTRO-xxxx-UD10
Telepath SMSC Introduction Guide Glossary
Glossary
A
ACK Acknowledgement - a Report from an SME.
AIM Application Interface Module. These Modules provide application-
specific functionality to Telepath SMSC. In general, they implement an
interface between remote Short Message Entities (SME), for example, a
VMS and tpkernel.
ASCII American Standard Code for Information Interchange. In relation to
Telepath SMSC specifically, this is the most common format for the text
of SMs to be sent in. In an ASCII file, each alphabetic, numeric, or special
character is represented with a 7-bit binary number (a string of seven 0s
or 1s). 128 possible characters are defined.
B
BMS Billing Management System
BSC Base Station Controller. This controls a number of base stations. It
handles signalling, traffic, and operations amd maintenance messages to
and from all BTSs under its control. Signalling messages are also passed
via the BSC.
BTS Base Transceiver Station. This is a radio base station which provides a
number of radio carriers and is responsible for logical to physical channel
mapping, channel coding, and channel ciphering.
C
Captive A user account defined by the system administrator to prevent
unauthorised access to data at the command line. Those assigned this
account bypass the UNIX command line and go straight to the TPSMT
interface.
CDR Call Detail Record. A CDR contains necessary information to bill
customers for message transactions.
CPU Central Processing Unit. This is the area in a computer which has circuits
that interpret and execute commands.
CUG Closed User Group. Members of a CUG can only send messages to other
subscribers within the group.
Customer A Telepath SMSC subscriber who can view, send, accept, replace and
delete Short Messages.
Cron cron is a UNIX utility which executes commands at regular specified
intervals, according to instructions found in the crontab file. The crontab
file can be found at /var/spool/cron/crontabs. The types of operations
which cron is particularly suited to are those which may affect system
performance during working hours. It is recommended therefore that the
cron job is run at off peak times.
SMS-2700-INTRO-xxxx-UD10 Glossary-1
Glossary Telepath SMSC Introduction Guide
DCS Data Coding Scheme. This is a field in the Messages.View command

form in TPSMT which indicates how the message was coded and whether
it supports foreign characters. Examples of types of coding available
include ASCII Unicode, EBCDIC etc.
DBMS Database Management System.
Destination Number The MSISDN/MSID of the message recipient.
DL Distribution List. An alias which can be used to send one message to a
number of customer names, rather than having to send the message to
each customer name individually. This is a list id. and not an MSISDN/
MSID.
DPC Destination Point Code. This defines the network address of remote
entities in the SINAP network.
E
ESMD External Short Message Descriptor. This is a table which is stored in
shared memory. Information on messages queued for each destination is
kept here.
ESME External Short Message Entity. An entity outside the mobile network that
can send messages to, or receive messages from an SMSC.
ESN Electronic Serial Number. This number is found in phone hardware and
is used, along with SIM card details by the EIR, to verify a subscribers
authenticity when a short message is submitted. If the phone has been
stolen, this will be apparent to the EIR.
F
FMS Fast Message Store.
FTP File Transfer Protocol. FTP is a program for transferring files on X.25
lines.
G
G/IW MSC Gateway/Interworking Mobile Switching Centre
GSM Group Special Mobile/Global System for Mobile Communications. A set
of standards for digital mobile communications developed by European
Telecommunications Standards Institute (ETSI).
GTT Global Title Translation. This is used for routing messages. Translation
involves using the Destination Point Code (DPC) and the Sub-System
Number (SSN) to send the message over the SS7 network. The translation
occurs at the Signalling Transfer Point (STP).
H
HLR Home Location Register - Repository of a GSM customers provisioning
data and current location register.
I
ID Identification integer which uniquely identifies the Short Message.
Glossary-2 SMS-2700-INTRO-xxxx-UD10
IMSI International Mobile Subscriber Identity. This is the main identity

number of a subscriber within the mobile network.
IPC Inter Process Communication. tpkernel interworks with the rest of
Telepath SMSC using a set of Interprocess Communication functions.
These functions allow a level of isolation to be maintained between the
processes of tpkernel and the other processes of Telepath SMSC.
IPM Inter Process Management.
K
KIF Kernel Interface Functions. A set of functions that support
communication with tpkernel. These functions which may be called
either locally or remotely, allow you to submit, receive, delete and query
Short Messages.
L
LogToDB Log to Database. An event action which logs events in the Telepath
SMSC database.
LPC Local Point Code. The LPC defines the SS7 network address of the local
platform. For example, the SS7 address of the SMSC. It is set only once,
that is the first time the platform is configured.
M
MCE Notification Memory Capacity Exceeded Notification. This is an alert which is sent to
an ESME which indicates that the subscriber’s SIM card is full. This
feature is used mainly on systems where Voice Mail Notifications
(VMNs) constitute the bulk of the traffic.
Message status area The lower area of the screen which displays status messages pertaining to
menu selections, commands or processes.
MIB Management Information Base. This is the RAM database that is used to
store information about the operational status of different parts of the
Telepath SMSC. It is created during system startup.
MN-IF Mobile Network Application Interface Module. This implements the
interface between the Service Centre and the PLMN. From tpkernel, this
module receives Short Messages for delivery to specific Mobile Stations.
From the PLMN, this module receives Short Messages, Reports and
Alerts for submission to tpkernel.
MO Mobile Originated.
MOP Message Operation Processing.
MO-SM Mobile Originated Short Message.
MS Mobile Station. An MS can be a source or sink of Short Messages.
MSC Mobile Switching Centre. This is the interface between the Base Station
Subsystem and the fixed network. It performs the necessary functions in
order to handle the calls to and from the Mobile Stations.
MSID Mobile Station Identifier. All mobile stations may be identified by one or
more of the following formats: IMSI, TMSI and MIN.
MSISDN Mobile Station International Integrated Services Digital Network. The

Mobile Station international ISDN number identifies an MS as ISDN
terminal. It is used to route calls from any international
telecommunications network (PSTN, ISDN, GSM-PLMN) to the MS.
MT Mobile Terminated.
MTP Message Transfer Protocol.
MT-SM Mobile Terminated Short Message.
MWD Override Message Waiting Data Override. When the MNIF queries the HLR for
the location of an SME, the HLR indicates that the MWD is set and an
SC-Alert is generated when the SME becomes available. No delivery
attempt is made. If however the message to be delivered is a Priority
message, then a delivery attempt will be made regardless of the MWD
setting.
MWI Message Waiting Indicator. An indication on a mobile handset that a
short text message has been sent to the subscriber.
N
Network Operator A company which provides SMSC services.
NMS Network Management System.
NPI Numbering Plan Indicator.
O
OA&M Operations, Administration & Maintenance.
OCOS Originating Class of Service. This is a field found in TPSMT Messages
menu screens that determines whether the subscriber can submit Short
Messages over a specific interface, for example SMPP.
P
PID (GSM) Protocol Identifier. This field can be found in the Messages.View
command form in TPSMT, and indicates which protocol, for example
SMPP, or external application, for example, the fax application, is being
used in the message operation.
PID Process Indentifier. Every process running on a system has a unique
identifier so that it can monitored and administered.
PLMN Public Land Mobile Network. A mobile telecommunications network
established by a provider to facilitate mobile telecommunications services. This
includes equipment, operations, and staff. A single provider may have more than
one PLMN.
Priority This field determines the priority level of a SM. It can be : Normal, High,
Higher or Highest.
PSTN Public Switched Telephone Network.
R
RDBMS Relational Database Management System.
Retry Date and Time the message was last attempted to be delivered.
RMT Resource Management Tool. This is used to monitor resources such as

HP OpenCall SS7 and X.25. It also supplies information about monitored
resources to applications via IPM-DBF interface.
S
SAM System Administration Manager. A UNIX System Administration tool
used to add UNIX users to the system, for example.
SAR System Analysis Report
SCCP Signalling Connection Control Part
SIU Signalling Interface Unit. This is the hardware part of the SS7 stack.
Layers MTP1 and MTP2 make up the SIU. Its function is to provide a
connection between SMSC and MSC and allow SS7 protocols to
communicate at both ends.
SM Short Message
SMS Short Message Service
Short Messaging A service defined within GSM for sending and receiving Short Messages
to/from a Mobile Station.
SMDPP ANSI-41 operation which is used by the Telepath SMSC to submit
Mobile Terminated Short Messages to the MSC and vice-versa.
SME Short Messaging Entity. Any source or sink of Short Messages. The
entity is either inside or outside the Public Land Mobile Network
(PLMN) and can send and/or receive Short Messages, for example,
Mobile Stations, Pagers, DTMF telephones.
SNMP Simple Network Management Protocol. This protocol defines a range of
transactions that enable SNMP Manager applications to monitor network
entities. An example of this type of entity would be the HP OpenView.
These entities are known as SNMP agents.
SMPP Short Message Peer-to-Peer.
Source Number The MSISDN/MIN number of the message originator.
SQL Structured Query Language. SQL is a comprehensive language for
organising, managing and retrieving data stored by a relational database.
SS7 Signalling System Number 7. Comunication Protocol used by Telepath
SMSC to communicate with the HLR and the MSC.
T
TCAP Transaction Capabilities
TCP/IP Transmission Control Protocol/Internet Protocol
TMSI Temporary Mobile Subscriber Identifier.
TON/NPI Type of Number/Numbering Plan Indicator. This makes up part of the
MSISDN/MIN.
TPCUST Telepath SMSC Customer application. Refer to the TPCUST User’s
Guide.
TPSMT Telepath SMSC System Manager Terminal. The application that supports
system administration and maintenance.
TPPROCUS Telepath SMSC Provisioning of Customers. This application provides an

inter-machine protocol for performing a wide range of Telepath SMSC
system administration, opreations and maintenance activities.
U
UCP Universal Computer Protocol. UCP is used by external systems to access
a paging service.
User Group Groups of subscribers who may be members of a corporate or managed
by a Service Provider.
V
VMA Voice Mail Alert. An indication that voice mail messages are present in
voice mailbox. Short Message may indicate voice mail present or may
also give an indication of how many messages.
VMS Voice Messaging System.
VPS Voice Processing System
X
X.25 A network protocol that enables computers on different public networks
to communicate through an intermediary computer at the network-layer
level. X.25 is the protocol adapter as standard by the CCITT.
Telepath SMSC Introduction Guide Index
Index
A interface 1-9
Address Routing 3-6, 3-14 DMM 1-13
address translation 3-5 mobile network 1-9
NMS 1-10
B Sierra 1-13
bdf command 7-4 SMPP 1-10
billing file TAP 1-11
file naming 6-5 TNPP 1-12
billing processes 6-3 TPCUST 1-11
BMS 2-10 TPSMT 1-11
C UCP 1-12
capacity licence monitor 5-2 K
classic messaging 2-3 Kernel 2-4
closed user groups 4-8
customer M
feedback -xiii MCE notification 3-19
validation 4-2 Message 2-12
message 2-13
D lengths 2-14
delivery mechanism controls 3-25 routing file 3-3
destination address validation 3-3 types 2-12
distribution lists 4-5 waiting data override 3-18
document conventions -xii message state
documentation deleted 2-13
related -xi delivered 2-13
E done 2-13
event for delivery 2-13
actions 8-5 undeliverable 2-13
classes 8-6 messaging modes
filtering 8-4 short messaging modes 2-2
log files 8-8 Mobile 1-9
logging thresholds 8-7 mobile registration delay 3-25
types 8-3 monitor
events 8-2 the UNIX system 7-4
expired message state 2-13 Monitoring 7-3
express messaging 2-7 monitoring the system 7-2
queues 2-7 MS registration delay 3-25
retry 2-8 MSC address storage 3-20
SMS alert notification 2-9 multi-recipient messages 3-24
extended device addressing 4-4 N
external environment 1-14 network cluster member formats 5-3
F normal
for delivery message 2-12
message state 2-13 O
G Overview 1-2
Global 3-19 overview of telepath SMSC 1-2
Global Title Addressing 3-14 P
H performance
hardware configuration 1-2 monitor system 7-4
home-location timezone 3-19 premium messaging 2-4
operations 2-5
I Prepaid 1-14
intended audience -x
SMS-2700-INTRO-xxxx-UD10 Index-1
Index Telepath SMSC Introduction Guide
priority message 2-12

process 7-3
process monitoring 7-3
proprietary software 1-2
provisioning customers 4-1
R
real time billing 2-10
related documentation -xi
retry 3-14
retry profiles
default schemes 3-17
retrys scheme 3-17
routing management 3-2
rtspooler 2-10
S
sar Command 7-4
scheduled
message 2-12
message state 2-13
service access control 4-5
short message
entities 1-14
responses 2-14
short message entity 1-14
short messaging modes 2-2
SME 1-14
SME table initialisation 2-12
source address validation 3-2
state 2-13
Structure -x
system performance
monitor 7-4
T
Telepath 1-6
Telepath SMSC
billing 6-2
external environment 1-14
introduction 1-2
local environment 1-2
overview 1-2
software 1-6
typographic conventions -xii
U
user groups 4-5
Index-2 SMS-2700-INTRO-xxxx-UD10
5 Custom House Plaza • Harbourmaster Place • Dublin 1 • Ireland
Tel +353 1 819 3400 • Fax +353 1 819 3401
Date:
Facsimile
To: Training & Documentation Department
At: + 353 1 819 3401
From:
Pages Including Cover:3
Message:
Dear Customer,
Could you please return, by fax, the attached Reader Comment form.
We welcome your involvement in our efforts to maintain the quality of our documentation. Any
comment that you wish to make about this manual will be greatly appreciated. After reading this
manual, please take the time to fill out the Reader Comment form overleaf and return it to us at
the above Fax Number.
Thank you for helping us improve our documentation!
NOTE: The information in this facsimile may be confidential, Proprietary and/or legally privileged information
intended only for the use of the individual or entity named above. If the reader of this message is not
the intended recipient, you are hereby notified that any copying, dissemination or distribution of
confidential, proprietary or privileged information is strictly prohibited. If you have received this
communication in error, please immediately notify us by telephone, and we will arrange for the return
of the facsimile. Thank you.
Reader’s Comment Form
Document Name: Telepath SMSC Introduction Guide
Document ID: SMS-2700-INTRO-xxxx-UD10

LogicaCMG welcomes any comments and suggestions that you may have on the quality and usefulness of this document.
Your feedback is an important element of the information used for revisions to our documentation. Feedback can be logged
to the response centre or submitted via e-mail to mndocs@logicaCMG.com.
• Did you find any errors in the document? Yes ❒ No ❒

(Indicate details below)
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
• Is the information clearly presented? Yes ❒ No ❒

__________________________________________________________________________________
__________________________________________________________________________________
• Do you feel that anything should be ADDED to the manual to improve it? Yes ❒ No ❒
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
• Are the examples correct? Was there a sufficient number of them? Yes ❒ No ❒
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
• Do any sections of the manual need to be expanded? Yes ❒ No ❒

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
• Do you feel any sections of the manual should be removed? Yes ❒ No ❒

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
TD007 Version 2.3

LogicaCMG
Custom House Plaza 5 • Harbourmaster Place • Dublin 1
Tel (+353)-1-8193400 • Fax (+353)-1-8193401
Reader’s Comment Form
• Do you have any other comments or suggestions for improvement? Yes ❒ No ❒

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
• What would you consider to be the STRONG points of the manual?

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
Please send your comments to:
Training and Documentation Manager

LogicaCMG
Custom House Plaza 5
Harbourmaster Place
Dublin 1
Ireland
e-mail: mndocs@logicaCMG.com
TD007 Version 2.3

LogicaCMG
Custom House Plaza 5 • Harbourmaster Place • Dublin 1
Tel (+353)-1-8193400 • Fax (+353)-1-8193401

Sms 2700 Intro XXXX Ud10

Uploaded by

Copyright:

Available Formats

You might also like

Sms 2700 Intro XXXX Ud10

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sms 2700 Intro XXXX Ud10

Uploaded by

Copyright:

Available Formats

Telepath SMSC Release 2700

Information contained in this document is proprietary and confidential to LogicaCMG. That

Logica Mobile Networks Limited,

Confidential and Copyright © LogicaCMG. 1996-2003

2.11 Predefined Messages .................................................................................2-14

4.5.3.2 Storage Throttle ...........................................................................................4-7

Figure 1-1: Context of Telepath SMSC ................................................................................. 1-2

Table 1-1: Telepath SMSC Core Processes ........................................................................... 1-6

Structure of this Document

This document comprises the following components:

• Chapter 1: Context of Telepath SMSC

• Chapter 2: Message Management

• Chapter 3: Message Validation and Routing

• Chapter 4: Provisioning Customers

• Chapter 5: Platform Management

• Chapter 6: Billing Customers

• Chapter 7: Monitoring the System

• Chapter 8: Event and Alarm Management

• Telepath SMSC Configuration Guide

Special Emphasis in Text

Font Convention Identifies

Bold Command names, variable values, field values and executables.

Italic Filenames, pathnames, variable names, field names and

Monospace File contents, program output and code examples.

Arial Text labels in illustrations.

Special Characters in Text

<> Variables to be specified by the user in command or file input

\ Continuation character in commands or lines of code that are

$ UNIX prompt for commands to be entered in the Bourne shell.

% UNIX prompt for commands to be entered in the C shell.

A documentation CD accompanies the software you have received from LogicaCMG.

Customer Training and Documentation Department

Telephone #: (353) 1 819 3400

1. Context of Telepath SMSC

This chapter comprises the following sections:

• Overview of Telepath SMSC

1.1 Overview of Telepath SMSC

Figure 1-1 provides an overview of Telepath SMSC

Non-MS Mobile Station

Provisioning Billing System

Figure 1-1: Context of Telepath SMSC

1. The Local Environment. This consists of:

1.2 Telepath SMSC Local Environment

The Telepath SMSC local environment consists of hardware configuration, proprietary

1.2.1 Hardware Configuration

Figure 1-2: Hardware Configuration

1.2.2 Proprietary Software

• HP-UX 11 Operating System

Application Interface Modules

Telepath Core Processes

UNIX Operating System

Figure 1-3: Telepath SMSC Architecture

1.2.3 Telepath SMSC Software

Process Name Description

tprmt This is LogicaCMG’s resource management tool, which is used to monitor

Process Name Description

tpcompleter After each delivery attempt, tpkernel receives an acknowledgement to say

tpTCLmonitor tpTCLmonitor is responsible for validating the operation and configuration of