USSD GATEWAYS

ESME
AND
GSM SERVICES
Terminology & concepts
SS#7 Signaling system 7
SSP Signaling switching points
SCP Signaling control points
STP Signaling transfer points
IP Intelligent peripheral
MSC Mobile switching center
HLR Home location register
VLR Visitor location register
MTP Message transfer part
SCCP Signaling connection control part
TCAP The transaction capabilities application part
GSM Global system for mobile communications
MS Message centre(mobile+sim)
BTS Base transceiver station
BSC Base station controller
G – MSC Gateway mobile switching centre
MSRN Mobile station roaming number
MSISDN Mobile station integrated services digital network
AUC Authentication centre
USSD Unstructured supplementary service data operations
PSSR Process unstructured supplementary services Request
USSR Unstructured supplementary services request
USSN Unstructured supplementary services notify
SMPP The Short Message Peer to Peer protocol
ESME External Short Message Entity
SMSC Short Message Service Center
SRI Send Routing Info For SM
Introduction
USSD GATEWAYS
A GSM communication technology used to send messages between a
mobile phone and an application server in the network. It is very much
similar to SMS, but USSD is session oriented as well as interactive. It
does not have store and forward concept. An USSD is a session based
protocol unlike SMS or MMS , therefore the session needs to be
allocated to each and every interaction.
Unstructured Supplementary Service Data, USSD, is a feature available
in GSM networks today. USSD is specified as part of the Mobile
Application Part, MAP. USSD is a session-oriented protocol suitable for
interactive, menu-driven sessions, where a subscriber requests text/data
from the system
USSD String
A USSD string is a command code (typically two or three digits)
followed by several parameters.
The parameters (supplementary information) have variable lengths and
are separated by the " * " key. The whole string is ended by the " # "
key.
 
Example of USSD strings: *123# , *121#
The syntax of a USSD string with a service code and service parameters
is mentioned below:
*<Command Code> *<Command parameters>#
Example of USSD strings: *123*12# , *121*12#
 
For a USSD Push we use SRI Messages which are sent to HLR to
receive information of IMSI and MSC number for MSISDN.
Why USSD ?
1) Quick Session Based Interaction. Faster than conventional.
2) GSM standard implementation and supported in all GSM
phones
3) No mobile changes needed to launch new services, and new
services can be Integrated with no network downtime or
additional mobile requirements
4) Reduced Marketing Costs. The same subscriber interface
will provide the new features implemented by the operator,
meaning less need to advertise and reduced marketing costs.
5)User does not have to remember all the short codes . Just a
master code can give access to all the services.
 
Typical call flow
 USSD Message Type
•Process unstructured supplementary services Request (PSSR):-
First message sent in case of Mobile Initiated (MI)USSD to initiate
USSD session. The response for this message from GW is USSR/USSN.

• Process unstructured supplementary services Request ACK (PSSR ACK):-

This message is the last message sent from GW to a
Specific PSSR to close the USSD session.

• Unstructured supplementary services request (USSR):-

This message is used to send the menu to subscriber.
Incase of Network Initiated USSD, this is the first message. Subscriber can reply to this message
with appropriate option.(1/2/3).

• Unstructured supplementary services request ACK (USSR ACK):-

This message contains the subscriber’s response to the menu sent in
USSR.
• Unstructured supplementary services notify (USSN):-
This message is sent from the GW to the subscriber. Subscriber cannot
reply to this message. It’s a simple flash on the handset.

• Unstructured supplementary services notify ACK (USSN ACK):-

Acknowledgment received once message in USSN flashes on
subscriber’s mobile.
Problems of the current system
In developing USSD Gateway, various features are to be included and
protocols need to be satisfied. It needs to maintain session for every
transaction that is made between subscriber and application. It needs to
identify a message form HLR is for which application, message from
application is for which subscriber.
USSD Gateway should be able to process at least 500 messages per
second. Therefore, while designing throughput should be taken into
consideration.
It also needs to convert MAP message into SMPP PDU so that it can be
delivered to application and SMPP PDU to MAP message so that it can
be delivered to HLR, hence to subscriber.
Ussd Support for multi digit short code e.g.
*1234*12*123*234#
Initial Features of system
Considering all the features that are visible till now, system
should contain the following functionalities:
 
Mobile Initiated USSD Requests
Network Initiated USSD Requests
Network Initiated USSD Notification
SMPP Protocol
MAP Compliance
Session Management
Timers
OVERVIEW OF OUR ORGANISATION
 GA
TE
WA
Y
Dailogic Stack
Dailogic Stack

ESME

HLR

PLATFORM

APPLICATION

External Network ONE 97 Network

SIGNALING SYSTEM7(SS#7)
Signaling System 7 is an architecture for performing “out of
band signaling” in PSTN (public switched telephone
network)
.
Signaling refers to “exchange of information” between
call components to maintain service.
 out of band signaling is one which does not take place to the
same path as conversation.
 Types Of Signaling

i. Associated signaling :- One link between each switch

reserved for signaling.

i.North American Signaling Architecture :

This defines a completely new network for signaling.

basic components of this network are
 Signaling switching points
 Signaling control points
 Signaling transfer points
Signaling switching points:-
These are telephone switches or end offices which
originate , terminate and switch calls.

Signaling control points :-

These are databases containing switching
information.

Signaling transfer points :-

These contain routing tables for further routing of
signals.
 The STP (Signaling Transfer Point)

The SS7 is held together through Signaling Transfer Point. There is no

need for connection in the SS7 network. the STP needs only to direct
messages to the links which it selects as most appropriate to deliver the
message.STP always exist in pairs called matted STP’s.

Cross link

The reason for the pairing of STPs is redundancy. If one of the pair
should be lost for any reason its “partner” STP will handle the load. The
links that connect the pair allow messages to cross over from one to
the other. They are, therefore, named “Cross Links” or simply “C”
links.
 The SSP (Signal Switching Point)
The SSP has the ability to stop call processing, make queries of even unknown
databases, and perform actions appropriate to the response. SSP is equipped
with whatever software is required to handle numerous feature capabilities.

The SCP (Service Control Point)

The SCP acts as the “front end” of the database. It may or may not be located in
the same location as the database. The important thing is that it can handle the
query and send the answer back to the switch required for routing .
SS7 stack
 MTP Level 1,2,3

Level 1 is called the physical layer. It deals with hardware and electrical
configuration.
Level 2 is the last to handle messages being transmitted and the first to handle
messages being received.
Level 3 functions are divided into two major categories. One of these is
Message Routing (or Signaling Message Handling). The other is Signaling
Network Management.
 Signaling Connection Control Part

SCCP Service Types

1) class 0 :- Usage, messages are transported without reference to other messages.
Delivery of messages is not guaranteed to be sequential.

2) class 1:- the SCCP calls on the servicesof MTP level 3 to modify its normal
handling of links in link sets.When asked to do so by SCCP, the MTP stops rotating
this code. The result is that the SLS stays the same, message after message. Messages
delivered on the same link remain in sequence.
 SCCP Specialized Routing Functions

Many of the chief benefits of the use of the SCCP lie in the specialized routing
functions. The addressing capabilities here are what allows the locating of database
information or the invoking of features at a switch. SCCP needs to provide addressing
which can be used to differentiate between databases or between various features or
services that can be invoked at a node. The value used is called a subsystem number.
Still another addressing mechanism is available to SCCP users. This one is known as
Global Title Translation (GTT).

The Transaction Capabilities Application Part

The purpose of TCAP is to allow applications to exchange information using signaling

that is not circuit related. It would also be accurate to say that TCAP is used largely by
switching locations to obtain data from databases (SSP from 800).
 Mobile Station (MS)
GSM refers to the cellular handsets as MS. The MS consists of the
physical equipment that the subscriber uses to access a Network and a
removable smart card, known as the SIM, to identify the subscriber.
The SIM card is fully portable between Mobile Equipment (ME) units.
This allows many features that we take for granted, such as being able to
swap MS simply by swapping our SIM card over. All functionality
continues seamlessly, including billing, and the telephone number
remains the same.
An MS has several associated identities, including the International
Mobile Equipment Identity (IMEI), the International Mobile Subscriber
Identity (IMSI), the Temporary Mobile Subscriber Identity (TMSI), and
the Mobile Station ISDN (MSISDN) number.
International Mobile Subscriber Identity(IMSI)

IMSI is a unique identification associated with all GSM

network mobile phone users.
It is stored as a 64 bit field in the SIM inside the phone and
is sent by the phone to the network.
 It is also used for acquiring other details of the mobile in
the Home Location Register (HLR) or as locally copied in
the Visitor Location Register.
The first 3 digits are the Mobile Country Code (MCC), and
is followed by the Mobile Network Code (MNC), 3
digits (North American standard). The remaining
digits are the mobile station identification number
(MSIN) within the network's customer base.
Example:
IMSI: 4041034567890
MCC 404 India
MNC 10 Airtel Delhi
MSIN 1234567890
 Temporary IMSI Number (TMSI)
A TMSI is an alias used by the VLR to protect subscriber
confidentiality. It is temporarily used as a substitute for the
IMSI to limit the number of times the IMSI is broadcast over
the air interface because intruders could use the IMSI to
identify a GSM subscriber.The VLR assigns the TMSI to an
MS during the subscriber's initial transaction with an MSC
(for example, location updating). Because the TMSI has only
local significance (within an area controlled by VLR), each
network administrator can choose its structure to suit his
needs.
 Mobile Station International ISDN
Number(MSISDN)
MSISDN is a number uniquely identifying a subscription in
a GSM mobile network.
It is the telephone number of the SIM card in a
mobile/cellular phone.
An MSISDN is limited to 15 digits.
It is combined of three parts:
1.Country Code
2. National Destination Code
3. Subscriber Number
Example:

MSISDN: 380561234567
CC 380 Ukraine
NDC 56 Dnipropetrovsk
SN 1234567 Subscriber's number
 Mobile Station Roaming Number(MSRN)
The Mobile Station Roaming Number (MSRN) is solely
used to route an incoming call. It is a temporary identifier that
is used to route a call from the gateway MSC to the serving
MSC/VLR.
The serving MSC/VLR is the MSC/VLR for the area where
the subscriber currently roams. The VLR assigns an MSRN
when it receives a request for routing information from the
HLR. When the call has been cleared down, the MSRN is
released back to the VLR.
 Mobile Application Part (MAP)

The MAP is an extension of the SS7/C7 protocols that are added

to support cellular networks. It defines the operations between the
MSC, the HLR, the VLR, the EIR, and the fixed-line network.
MAP specifies a set of services and the information flows
between GSM components to implement these services.
MAP uses TCAP over SCCP and MTP. TCAP correlates
between individual operations. The TCAP transaction sub layer
manages transactions on an end-to-end basis. The TCAP
component sub layer correlates commands and responses within a
dialog.
POINT CODES
 Overview

1. It is a unique address for a signaling point in a SS7 network.

2. It is used in MTP-3 layer for identifying host and destination and
routing packets to correct location or MTP.
These are OPC – Originating Point Code and DPC – Destination Point
Code
3. these point codes are carried by MSU's.
4. Point codes are present in SIF(Signalling Information Field) inside the
routing label.
THE SHORT MESSAGE PEER TO PEER
PROTOCOL (SMPP)
Short Message Peer to Peer (SMPP) protocol is an open message-transfer protocol
that enables short message entities (SMEs) outside the mobile network to interface
with an SMSC. Non mobile entities that submit messages to, or receive messages
from an SMSC are known as External Short Message Entities (ESMEs).

The SMPP protocol defines:

• a set of operations for the exchange of short messages between an

ESME and an SMSC
• the data that an ESME application must exchange with an SMSC
during SMPP operations.
 SMPP messages sent from ESME to SMSC/Gateway

An ESME which sends short messages to an SMSC must be connected to the SMSC as
an ESME Transmitter or an ESME Transceiver. Examples of SMPP message Protocol
Data Units (PDUs) which may be sent from an ESME transmitter to the SMSC
include:-
• submit_sm
• data_sm

In addition to submission of messages to the SMSC, an ESME may perform the

following SMPP operations using the message identifier returned by the SMSC in the
message acknowledgement:-
• query_sm - Query the SMSC for the status of a previously submitted message
• cancel_sm - Cancel delivery of a previously submitted message
• replace_sm - Replace a previously submitted message
 SMPP Message Response from SMSC/Gateway to ESME
The SMPP PDU response for a message submission to the SMSC will include a
message identifier (which must be a unique handle assigned to that particular message)
and a status which informs the ESME whether the submitted message is valid (i.e.
accepted by the SMSC for onward delivery) or invalid. In the latter case, the SMSC
will return an appropriate error status.

• submit_sm_resp
• data_sm_resp
• query_sm_resp
• cancel_sm_resp
• replace_sm_resp

* for alert_notification pdu no acknowledgment required.

 “GENERIC_NACK” PDU

This is a generic negative acknowledgement to an SMPP PDU submitted with an

invalid message header. A generic_nack response is returned in the following cases:

• Invalid command_length :- If the receiving SMPP entity, on decoding

an SMPP PDU, detects an invalid command_length (either too short or too long), it
should assume that the data is corrupt. In such cases a generic_nack PDU must be
returned to the message originator.
• Unknown command_id :- If an unknown or invalid command_id is received, a
generic_nack PDU must also be returned to the originator.

“SUBMIT_MULTI” Operation

The submit_multi operation may be used to submit an SMPP message for delivery to
multiple recipients or to one or more Distribution Lists. The submit_multi PDU does
not support the transaction message mode
The exchange of messages between an ESME(external short message entity) and
SMSC(short message service center) via SMPP may be categorized under three
distinct groups of transactions as follows :-

i) Transmitter :-Messages sent from the ESME to the SMSC.

ii) Receiver:- Messages sent from the SMSC to the ESME.
iii) Transceiver:- Messages sent from the ESME to the SMSC and
messages sent from the SMSC to the ESME.
 SMPP messages sent from SMSC to ESME

The SMSC may deliver short messages to an ESME. In this case the ESME must be
connected to the SMSC as an ESME Receiver or as an ESME Transceiver
Examples of SMPP message Protocol Data Units (PDUs) which may be sent from an
SMSC to an ESME receiver include:

• deliver_sm
• data_sm

“DELIVER_SM” Operation

The deliver_sm is issued by the SMSC to send a message to an ESME. Using this
command, the SMSC may route a short message to the ESME for delivery.
ESME Transceiver
 PROTOCOLS USED

XML

ESME
SMPP
USSD GATEWAY
Dialogic
Stack

MAP

HLR
Dialogic Configuration
Dialogic® High Density SS7 Boards include specialized T1/E1 SS7 signaling
boards for use in PCI,CompactPCI and PCI Express systems. The boards offer
a common software API to the application that enables applications to be ported
easily between hardware architectures.
The high density SS7 boards include PCI, CompactPCI and PCI Express form
factors. The CompactPCI boards are available with different rear transition
modules to allow a range of different physical interfaces options.
 
Each signaling processor is capable of handling up to 32 SS7 signaling links or
a single high-speed SS7 link (HSL). The selection is determined when the first
or only link is configured on a signaling processor. A single code file contains
all the necessary software and firmware.
The boards provide a suitable hardware platform for running Dialogic® SS7
Protocols for the realization of Signaling System Number 7 signaling nodes. In
addition, the SS7HD boards can be used to build high performance monitoring
applications. The boards can be used under the Linux, Solaris, and Windows®
operating systems.
FUNCTION AND FILES PROVIDED
ESME OUTLOOK
 BASIC CLASS INFORMATION

1. Receiver Class to receive PDU from Gateway Stack.

1. Sender Class to send XML packet to Platform .

1. XML Exchanger which convert SMPP PDU to XML object.

1. SMPP Exchanger which convert XML object to SMPP PDU

1. Main Worker Threads for this conversion purposes.

1. Object Manager to Maintain Connectivity.

Description:

ESME receives SMPP PDU's from dialogic stack and convert them to XML objects
and send them to USSD platform for further processing.

ESME receives XML objects from Platform and convert them to SMPP PDU's and send them to
Gateway.

For this ESME maintain worker threads that keep listening on different sockets to receive and
send data

Communication starts when ESME receive deliver_sm from Gateway for a particular
Msisdn request.
ESME parse SMPP PDU and convert it to XML object and send a “IN” request to Platform
Platform replies with “MID” and “REL” or “MID” and “CON”
If it is “MID” and “REL” than session is terminated by sending “TR” packet
If it is “MID” and “CON” than session is reply is send back to the mobile user which can be a
USSR – to continue the request or USSN to thank the user .
 IN
SMPP

XML
SMPP
ESME
MID (CON)
MID(CON )1
ENGINE
SUBMIT SM
MID REL

RESPONSE
DELIEVER SM

RESPONE

USSD GATEWAY

MESAGE
1
MAP
REPLY

MESSAGE 1
HLR
REPLY
NETWORK
 USSD SERVICES
FOR NO INTERACTIVE USERS
IN
message

smpp
ESME xml ENGINE
smpp mid-->REL

USSD_Gateway

map

HLR Netw
USS ork
N

Mobile
 USSD BLOCK DIAGRAM

IN
SMPP

GATEWAY ESME ENGINE

SMPP XML
MAP
HLR

MOBILE
USSD AND GATEWAY
RELATIONSHIP
Gateway
S
Response- U
SM B
D
M
E
I
L
T
I
T
V
E
E
D
R
-SM
-
SM
ESME
USSD IMPLEMENTATION
 Module Description

The design of the USSD Gateway mainly constitutes of message flow

between one function to another function. SMPP LISTENER listens all
incoming packets from ESME and will pass PDU’s to the SMPP
MESSAGE. SMPP MESSAGE sends messages to the MAP MESSAGE
received from SMPP LISTENER and sends response messages with
appropriate status to the ESME. In case of error, depending on the type
of error, command status is set. In case of success, positive
acknowledgement is sent towards ESME. MAP LISTENER listens all
incoming messages from DIALOGIC STACK and calls function stored
in MAP MESSAGE class. MAP MESSAGE sends message to the SMPP
MESSAGE received from MAP LISTENER. It sends response message,
In case of error (ESME not connected, invalid message etc), depending
on type of error, command status is set, In case of success, positive
acknowledgement is sent
 DIALOGIC STACK TO THE ESME

5/22/11
 E S M E

U S S D T IM E R

M A P P IN G U S S D U T IL S
IN F O E N C O D IN G
S M P P
M E S S A G E S
A C T IV E
S E S S IO N S E S S IO N E S M E
O B JE C T M A N A G E R IN F O

M A P M E S S A G E S
M A P P IN G
H A N D L IN G
U P D A T E M A P P IN G IN F O
F U N C T IO N S
IF N E W M S IS D N

R E S P O N S E
P D U

M A P L IS T E N E R

D IA L O G IC
S T A C K
Features of USSD Gateway
Considering all the features that are visible till now, system should
contain the following functionalities:
 
Mobile Initiated USSD Requests: Subscribers can send requests to
applications that are configured on the USSD Gateway. The subscribers
may send these requests to retrieve information or to make enquires.
Network Initiated USSD Requests: Gateway applications or services
can send out requests to Subscribers prompting for information or data.
Network Initiated USSD Notification: Subscriber specific
notifications may be sent out by the USSD services.
SMPP Protocol: USSD Gateway uses the SMPP protocol (version 3.4)
for communication with external applications.
MAP Compliance: The USSD gateway is compliant with both GSM
MAP Phase I and Phase II USSD requirements.
Logs: To identify bottlenecks and monitor system performance, the
system records all events and activities in logs. These logs are used to
track events and errors in case of problems.
•Database: For authentication of the external application connected to
the gateway, database is maintained. Also it would be used for the
purpose of load throttling, for restricting the ESME to limited/defined set
of messages.
•Session Management: Session is maintained for communicating with
the subscriber.
•Timers: Timers are used to close and delete session if response does
not arrive in a stipulated period.
•Statistics: They are maintained for each application connected to the
gateway. It maintains how many sessions are maintained for an
application in an hour. It also maintain total number of requests, number
of session with one request-response, two request-response, three
request-response and four & more request-response messages arrived for
an application.
•Load manager: It checks the load for each application connected to
gateway does not allow them to exceed the prescribed limit.
MY CONTRIBUTIONS
 Tested application module using simulators
 Constructed test cases for Network Module
 Made Design Document for the project
 Tested ESME Module for different shortcodes
 Coded scripts for automating deployment of all modules
 Integration of EAGLE API with USSD
 Changes In existing code.
REQUIREMENT ELICITATION
USSD Gateway will interact with HLR and ESME
Communication with HLR is done using MAP protocol via
Dialogic stack.
Communication with ESME is done using SMPP protocol
via Socket programming
PSSR , USSR , USSN messages are to be studied in MAP
protocol
DELIVER_SM, SUBMIT_SM messages are to be studied in
SMPP protocol
Different modules will be made for different protocols
Requirement of Eagle Api
Requirement of automating the deployment process
Embedding new short codes e.g. 4 digit short codes *1234#
REQUIREMENT SPECIFICATION
The analysis model must achieve three primary objectives:
 
1. To describe what the customer requires.
2. To establish a basis for the creation of a software design.
3. To define a set of requirements that can be validated once
the software is build.
DESIGN
Module View 1
It describes the network architecture in which USSD Gateway will be
placed. The USSD subscriber can use the service by dialing a USSD string
(a USSD short code) and the optional service related information.

S M P P P D U ’s A p p lic a t io n
T C P /IP

S M P P P D U ’s
R a d io S ig n a llin g
T C P /IP
SS7 H LR
SS7 S ig n a llin g M AP
S ig n a llin g M e ssag es
A p p lic a t io n C lie n t
M S C /V L R U S S D G a te w a y
S M P P P D U ’s
M YSQL
T C P /IP

Database
Module view 2

The design of the USSD Gateway consists of two modules i.e.

Network Module and Application Module. The division of the
modules is done as per the interaction with the type of
Network.

Database

M YSQL

M a p M e ssag e s

N e tw o rk
HLR M o d u le
X M L S t r in g s
A p p lic a tio n SMPP PDUs ESM E
M o d u le

U S S D G a te w a y
Module view 3

It displays the detailed description of layers and modules.

The Network Module is responsible for handling the messages
from HLR and therefore maintaining the communication with
the SS7 Network. The Application Module interacts with the
ESME entities over the SMPP interface using the IP network.
The interaction among the modules is performed using the
XML strings over sockets.
 E S M E E S M E E S M E
( A p p lic a tio n ( A p p lic a tio n ( A p p lic a tio n
C l i e n t) C l i e n t) C l i e n t)

T C P /IP
IP N e tw o r k

E S M E H a n d le r

N e tw o r k T o S e s s io n L o a d S t a t is t ic s E S M E T o A p p lic a t io n M o d u le
E S M E M a n a g e r M a n a g e r M a n a g e r N e tw o r k

M A P C lie n t

T C P /IP T C P /IP

P ro ce sso r R e c e iv e r N e t w o rk M o d u le
R e c e iv e r P ro ce sso r

U S S D G a te w a y

D ia lo g ic S t a c k

S S 7

S S 7 N e tw o rk
S S 7

H L R
LOGICAL DESIGN
 D a ta D a ta
M A P M essa ge M AP O b je c t O b je c t M AP X M L S tr in g
R e c e iv e r W o rke r

O b je c t

D ia lo g ic O b je c t
Pool
T im e r s A p p lic a t io n
S ta c k O b je c t
O b je c t M a n a g e r M o d u le
( O b je c t P o o l m a in ta in s o b je c t fo r s e s s io n m a n a n g e m e n t )

M A P M essa ge
A p p lic a tio n A p p lic a tio n
W o rke r A p p lic a tio n A p p lic a tio n R e c e iv e r X M L S tr in g
O b je c t O b je c t
DATABASE DESIGN
 ESME Details
ESME Details

It contains data about each application connected to USSD Gateway.

Esme Details

IP ussdString userName pswd ldCapacity

ussdgateway

Id Password Shortcode Dpc range

Time Shortcode User Error Type

TESTING
Software Requirements
 
•MySQL 5.1x
•mysql++3.0.9
•libsmpp34-beta-1.8.1
•g++/gcc compiler
•Tomcat 6.0
•Linux OS
•JDK/JRE 1.6
•Tomcat 6.0
•Libcurl 3.07
Test Environment
 
Testing is done on the following environments ---
 
Dialogic stack
Tomcat 6.0
MySQL 5.1.32
mysql++3.0.9
libsmpp34-beta-1.8.1
Install g++
RAM – 2GB
Hard Disk – 120GB
Quartz code Intel processor
 
Test Cases
 
Network module is attached to network, hence will receive the
MAP messages from the stack.

Module Name Network Module

Test Case No.
Requirement System is connected to network and SMPP module.
System is up.
Test condition Messages are received
Expected Results Messages received and corresponding response
messages are send.
Module Name Network Module
Test Case No.
Requirement MAP_OPEN_IND send by simulator
Test condition MAP_OPEN_IND received with valid parameters

Module Name Network Module

Test Case No.
Requirement MAP_PSSR_IND send by simulator
Test condition MAP_PSSR_IND received with valid parameters
Expected Results PSSR_REQ sent to SMPP module

Module Name Network Module

Test Case No.
Requirement MAP_USSR_CNF send by simulator
Test condition MAP_USSR_CNF received with valid parameters
Expected Results USSR_RSP sent to SMPP module
Module Name Network Module
Test Case No.
Requirement MAP_OPEN_CNF send by simulator
Test condition MAP_OPEN_CNF received with dialogue accepted
Expected Results Do nothing

Module Name Network Module

Test Case No.
Requirement MAP_U_ABORT_IND send by simulator
Test condition MAP_U_ABORT_IND received
Expected Results Free the object

Module Name Network Module

Test Case No.
Requirement MAP_CLOSE_IND send by simulator
Test condition MAP_CLOSE_IND received
Expected Results Free the object
Module Name Network Module
Test Case No.
Requirement Application is ready to accept MSG from simulator
Test condition MAP_PSSR_RSP received
Expected Results Drop the message, it is not expected

Module Name Network Module

Test Case No.
Requirement Application is ready to accept MSG from simulator
Test condition MAP_USSR_IND received
Expected Results Drop the message, it is not expected

Module Name Network Module

Test Case No.
Requirement Application is ready to accept MSG from simulator
Test condition MAP_USSN_IND received
Expected Results Drop the message, it is not expected
Module Name Automation Script
Test Case No.
Requirement Script and all necessary modules binary for 32 and
64 bit system
Test condition
Expected Results Modules are deployed
Test Cases for Gateway
 S M P P P L IS T E N E R
S M P P H A N L IN G
ESM E D E C O D IN G
1 . D E C O D E C O M M A N D ID F U N C T IO N B A S E D O N
O N LY C O M M A N D ID

IF U N B IN D IF B IN D YES
YES R EQUEST
NO REQUEST
A C T IV E
ESM E
IN F O
U S E D O N L Y IN C A S E O F
B IN D R E Q U E S T

UPD ATE YES

SU CC ESS A U T H E N T IC A T IO N

M A P IN F O
C REATE
R ESPON SE PD U
O N T H E B A S IS
O F S U C C E S O R F A IL U R E
U SSD
S E S S IO N C O N F IG
O BJEC T
O N L Y IN T H E
C A S E O F U N B IN D

S E S S IO N C REATE
SEN D TO
M ANAGER RESPONSE
ESM E
PD U
ESME TO DIALOGIC STACK
 s e rv e r
c lie n t
S M P P P L IS T E N E R
S M P P H A N L IN G
F U N C T IO N B A S E D O N
E S M E D E C O D E C O M M A N D ID C O M M A N D ID
O N L Y

D E C O D IN G

A C T IV E
E S M E
IN F O

V A L ID A T IO N

C R E A T E
C R E A T E R E S P O N S E
S E N D T O P D U O N T H E
R E S P O N S E B A S IS O F
S U C C E S S M A P IN F O
E S M E
P D U S U C C E S O R
F A IL U R E

Y E S

M A P
S E S S IO N S E S S IO N
M E S S A G E S
O B J E C T M A N A G E R

S E N D T O D IA L O G IC
S T A C K
MY LEARNINGS
•GSM Network study – Studied the network and its various
elements.
•SS7 Network study - Studied the network and its various
signaling points.
•MAP messages to send or received on the USSD Gateway.
•API of Dialogic Stack for sending messages of MAP
protocol.
•SMPP messages
•Configuration of Dialogic stack
•Eagle Api
•Shell Script
TYPICAL APPLICATIONS:
•Balance Check: The user can send a Process Supplementary Service
request (PSSR) to the home zone which will forward this, under
guidance from the Gateway, to the correct application. Then, the
application sends an acknowledgement via USSD Gateway, HLR etc,
known as PSSR response back to the user. Balance Notification at the
end of charged call can also be given using Unstructured Supplementary
Service Notify (USSN) message.
•Voice Chat: Using the same process as above, one can use voice chat.
This is highly useful when VoIP enabled phones are not available.
•Advertising: The application can advertise their product using USSD
which is less invasive than telemarketing.
•Roaming: This has huge advantages while roaming. This is because
USSD services are well available in roaming networks and all the USSD
messages are directed towards the subscriber's Home Network itself,
thus, same set of services that are available in home network can be
given in visited network too, giving subscribers a Virtual Home
Environment (VHE).