presentation 1
TRANSCRIPT
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).