Presentation 1

USSD GATEWAYSESMEAND

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

IMSI International mobile subscriber identity

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 phones3) No mobile changes needed to launch new services, and new services can be Integrated with no network downtime or additional mobile requirements4) 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 RequestsNetwork Initiated USSD RequestsNetwork Initiated USSD Notification SMPP ProtocolMAP ComplianceSession ManagementTimers

OVERVIEW OF OUR ORGANISATION

HLR

Dailogic Stack

External Network

Dailogic Stack

GATEWAY

ESME

PLATFORM

APPLICATION

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.

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 tothe other. They are, therefore, named “Cross Links” or simply “C” links.

Cross link

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 equippedwith 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 handlemessages 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 Types1) 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 IndiaMNC 10 Airtel DelhiMSIN 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 Code2. National Destination Code3. Subscriber Number

Example:

MSISDN: 380561234567CC 380 UkraineNDC 56 DnipropetrovskSN 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 Code3. 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 TransceiverExamples 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

ESME

PROTOCOLS USED

USSD GATEWAY

HLR

MAP

SMPP

XML

Dialogic Stack

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 objectsand 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 particularMsisdn request.ESME parse SMPP PDU and convert it to XML object and send a “IN” request to PlatformPlatform 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

ENGINEESME

USSD GATEWAY

HLRNETWORK

SMPP

XML

SUBMIT SM

MAP

SMPP

RESPONSE

MESAGE 1

MESSAGE 1

REPLY

REPLY

DELIEVER SM

RESPONE

MID(CON )1

MID REL

MID (CON)

IN

ESME ENGINE

USSD_Gateway

HLR Network

Mobile

USSN

message

smpp

xmlsmpp

map

mid-->REL

USSD SERVICES FOR NO INTERACTIVE USERS

IN

ESME ENGINEGATEWAY

HLR

SMPP

XMLSMPPMAP

MOBILE

USSD BLOCK DIAGRAM

Gateway

ESME

DELIVER-SM

SUBMITTED-SM

Response-SM

USSD AND GATEWAY RELATIONSHIP

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

M A P L IS T E N E R

M A P P IN G IN F O

M A P M E S S A GE SH A N D LIN G

F U N C T ION S

S E S S ION M A N A GE R

S M P P M E S S A GE S

S E S S ION OB JE C T

E S M E

D IA LOGICS T A C K

R E S P ON S EP D U

U P D A T E M A P P IN GIF N E W M S IS D N

U SSD U TILSEN C OD IN G

A C T IV E E S M EIN F O

M A P P IN G IN F O

U S S D T IM E R

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 ESMECommunication with HLR is done using MAP protocol via Dialogic stack.Communication with ESME is done using SMPP protocol via Socket programmingPSSR , USSR , USSN messages are to be studied in MAP protocol DELIVER_SM, SUBMIT_SM messages are to be studied in SMPP protocolDifferent modules will be made for different protocolsRequirement of Eagle ApiRequirement of automating the deployment processEmbedding 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.

USSD Gateway

Application

Application C lient

Database

M S C/V LR

Application C lient

HLR

Radio Signalling

SS7 Signalling

SS 7 Signalling MAP

Messages

SMPP PDU’sTCP/IP

SMPP PDU’sTCP/IP

SMPP PDU’sTCP/IP

MYSQL

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.

H LR

U SSD G atew ay

ESM ENetwork M odule Application

M odule

Map Messages

XML StringsSMPP PDUs

Database

MYSQL

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.

IP Network

SS7 N etwo rk

H LR

E S M E(A p p l ica tio n

C l ie n t)

D ialogic S tack

Processor

Receiver

Receiver

Processor

MAP C lient

Network To Session Load Statistics ESME To ESME Manager Manager Manager Network

ESME Handler

Application Module

N etw ork Module

USSD Gateway

E S M E(A p p l ica tio n

C l ie n t)

E S M E(A p p l ica tio n

C l ie n t)

TC P/IP

SS7

SS7

TCP/IPTCP/IP

LOGICAL DESIGN

Dialogic Stack

Application Module

MAPReceiver

MAPWorker

ApplicationReceiver

ApplicationWorker

Object Manager(Object Pool maintains object for session manangement )

Object Pool T imers

MAP Message

MAP Message

ApplicationObject

ApplicationObject

DataObject

DataObject

XML String

XML String

Object

Object

DATABASE DESIGN

ESME Details

It contains data about each application connected to USSD Gateway.Esme Details

ESME Details

IP ussdString userName pswd ldCapacity

Id Password Shortcode Dpc range

Time Shortcode User Error Type

ussdgateway

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 stackTomcat 6.0MySQL 5.1.32 mysql++3.0.9libsmpp34-beta-1.8.1Install g++RAM – 2GBHard Disk – 120GBQuartz code Intel processor 

Test Cases Network module is attached to network, hence will receive the MAP messages from the stack.

Module Name Network ModuleTest Case No.Requirement System is connected to network and SMPP module.

System is up.Test condition Messages are receivedExpected Results Messages received and corresponding response

messages are send.

Module Name Network ModuleTest Case No.Requirement MAP_OPEN_IND send by simulatorTest condition MAP_OPEN_IND received with valid parameters

Module Name Network ModuleTest Case No.Requirement MAP_PSSR_IND send by simulatorTest condition MAP_PSSR_IND received with valid parametersExpected Results PSSR_REQ sent to SMPP module

Module Name Network ModuleTest Case No.Requirement MAP_USSR_CNF send by simulatorTest condition MAP_USSR_CNF received with valid parametersExpected Results USSR_RSP sent to SMPP module

Module Name Network ModuleTest Case No.Requirement MAP_OPEN_CNF send by simulatorTest condition MAP_OPEN_CNF received with dialogue acceptedExpected Results Do nothing

Module Name Network ModuleTest Case No.Requirement MAP_U_ABORT_IND send by simulatorTest condition MAP_U_ABORT_IND receivedExpected Results Free the object

Module Name Network ModuleTest Case No.Requirement MAP_CLOSE_IND send by simulatorTest condition MAP_CLOSE_IND receivedExpected Results Free the object

Module Name Network ModuleTest Case No.Requirement Application is ready to accept MSG from simulatorTest condition MAP_PSSR_RSP receivedExpected Results Drop the message, it is not expected

Module Name Network ModuleTest Case No.Requirement Application is ready to accept MSG from simulatorTest condition MAP_USSR_IND receivedExpected Results Drop the message, it is not expected

Module Name Network ModuleTest Case No.Requirement Application is ready to accept MSG from simulatorTest condition MAP_USSN_IND receivedExpected Results Drop the message, it is not expected

Module Name Automation ScriptTest Case No.Requirement Script and all necessary modules binary for 32 and

64 bit systemTest conditionExpected Results Modules are deployed

Test Cases for Gateway

AU TH EN TIC ATIONS U C C E S S

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

U S S D C ON F IG

M A P IN F O

U P D A T E

C R E A T E R E S P ON S E

P D U

S E N D T O E S M E

SESSION MAN AGER

SESSION OBJEC T

U SED ON LY IN C ASE OF BIN D R EQU EST

Y E S

ON LY IN TH E C ASE OF U N BIN D

1 . D E C O D E C O M M A N D ID O N L Y

ESME

SMPPP LISTEN ERS M P P H A N LIN G

F U N C T ION B A S E D ON C OM M A N D ID

D E C OD IN G

Y E SIF B IN D

R EQU ESTY E SIF U N BIN D

R EQU EST N O

C R EATER ESPON SE PD U ON TH E BASIS

OF SU C C ES OR FAILU R E

ESME TO DIALOGIC STACK

VALID ATION

SU C C ESS

AC TIVE ESME IN FO

MAP IN FOC R EATE

R ESPON SE PD U

SEN D TO ESME

SESSION MAN AGER

SESSIONOBJEC T

MAP MESSAGES

YES

CREATE RESPONSE

PDU ON THE BASIS OF

SUCCES OR FAILURE

SEN D TO D IALOGICSTAC K

client

server

ESME

SMPP H AN LIN G FU N C TION BASED ON

C OMMAN D ID

D EC OD IN G

D E C O D E C O M M A N D ID O N L Y

SMPPP LISTEN ER

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).