Traffic Control

Transact Module
 Transact Training Agenda

• Short intro to USSD

• SS7 Opcodes and Message Types
• Legacy ESME/Transactional/Multi-Step ESME
• Call flows
• Architecture
• GUI configuration
• Troubleshooting
• Examples & Questions
 USSD Overview
• Unstructured Supplementary Service Data (USSD) is a protocol used by GSM
cellular telephones to communicate with the service provider's computers.
USSD can be used for WAP browsing, prepaid callback service, mobile-money
services, location-based content services, menu-based information services,
and as part of configuring the phone on the network.
• USSD is defined within the GSM standard in the documents GSM 02.90 (USSD
Stage 1) and GSM 03.90 (USSD Stage 2)
• There are two modes of operation – mobile initiated (pull) and application
initiated (push)
• USSD Phase 1, specified in GSM 02.90, only supports mobile-initiated ("pull")
operation. In the core network, the message is delivered over MAP. USSD
Phase 2, specified in GSM 03.90, supports network-initiated ("push")
operation as well.
• Unlike Short Message Service (SMS) messages, USSD messages create a
real-time connection during a USSD session. The connection remains open,
allowing a two-way exchange of a sequence of data
 USSD Overview - Continue
• Turnaround response times for interactive applications are shorter for USSD
than SMS because of the session-based feature of USSD, and because it is
NOT a store and forward service – near real time.
• USSD commands are routed back to the home mobile network’s Home
Location Register (HLR) - works in exactly the same way when users are
roaming
• Users do not need to access any particular phone menu to access services
with USSD - they can enter the USSD command direct from the initial mobile
phone screen
• USSD commands can be sent from all existing GSM mobile phones
• USSD commands are simple to form and easy to send - composed using
digits and the #, * keys
• User can directly enter the USSD string and press Call to send the message
• USSD messages are up to 182 alphanumeric characters in length.
 Supported GSM MAP Operations and
Opcodes
• Opcode 19 - ProcessUnstructuredSS-Data (PSSD)
PSSD request is a Phase 1 MO sent from handset – this message is very
rarely seen – very few handsets will generate this message
• Opcode 59 – ProcessUnstructuredSS-Request (PSSR)
PSSR Request is Phase 2 MO sent from handset – the message will typically
be a command like *#101#
• Opcode 60 – UnstructuredSS-Request (USSR)
This is a push message sent to the handset from TC – the handset will be
prompted to respond to the message
• Opcode 61 – UnstructuredSS-Notify (USSN)
This is a push message sent to the handset from TC – the handset will not be
prompted to respond to the message
 SMPP Protocol Support

• SMPP specification defines an optional TLV which

can be included in the SMPP message to identify a
USSD operation (TLV = 0x0501)
• The optional parameter is 'ussd_service_op' and is
defined in section 5.3.2.44 of the SMPP Protocol
Specification (v3.4)
• The 'ussd_service_op' parameter is required to
define the USSD service operation when SMPP is
being used as an interface to a (GSM) USSD
system
 SMPP Protocol TLV definitions

TLV '0x0501' value specifies SS7 USSD Operation:

• 0 PSSD Request (to ESME)
• 16 PSSD Response (from ESME)
• 1 PSSR Request (to ESME)
• 17 PSSR Response (from ESME)
• 2 USSR Request (from ESME)
• 18 USSR Response (to ESME)
• 3 USSR Notification Request (from ESME)
• 19 USSR Notification Response (to ESME)
 SMPP Transact Vendor Extensions
Specific Vendor SMPP Extensions

• 32 Dialog close (from ESME – normal dialog closure)

• 33 Dialog abort (to ESME – abnormal dialog closure)
 SMPP Protocol Extension
TRANSACT defines two additional SMPP TLVs which are required to
support multi-message dialogue with an external ESME

• ESME USSD Dialogue ID (TLV = 0x1800)

For ESME­originated SMPP request and response messages, a vendor TLV
may be optionally used by the ESME to pass an ESME­assigned USSD
dialogue ID. TRANSACT will honor this reference and re­use in any
subsequent response or request messages.

• SMSC USSD Dialogue ID (TLV = 0x1801)

For TRANSACT­originated request and response messages, a vendor TLV
will be used to pass a SMSC-assigned USSD dialogue ID. The ESME must
re-use this TLV in all subsequent exchanges on the same dialog.
 SMPP USSD ESME Types
TRANSACT supports three distinct types of ESME for USSD
interworking

• TRANSACT compatible (Transactional mode)

- Compatible ESME can encode all required USSD TLVs
- Multi-message dialogues are supported
- More efficient for SMPP traditional ESMEs

• Legacy (also referred to as Simple)

- Legacy ESMEs are not capable of encoding USSD TLVs.
- Multi-message dialogues cannot be supported
- If the USSD operation is not specified in an ESME originated
message then the default operation is USSN

• Multi-Step
- same as transactional compatible mode but different flow –
specifically designed for Web service endpoints
Call Flows
Legacy ESME Support
MO Phase 2 Pull (Transactional ESME) – no dialogue
Phase 2 MO-AT Dialogue (Transactional ESME)
Phase 2 AO – MT (Transactional ESME) – no dialogue
Phase 2 AO – MT (Transactional ESME) – dialogue
Abort Usage Scenario
MO Phase 2 Pull (Multi-Step ESME) – no dialogue
MO Phase 2 Pull (Multi-Step ESME) – dialogue
AO -MT Phase 2 (Multi-Step ESME) – no dialogue
AO -MT Phase 2 (Multi-Step ESME) – dialogue
TRANSACT Overview
 TRANSACT Architecture

ESME
jimi drum

g2c CORE ROUTING BUS SMPP

Web
Service
gummi
reafer
HTTP
frosti
xena
simpson

Core Network
 Transact Components

●
gummi – TCAP client
Connects to the TCAP server (frosti) and performs the GSM encoding and
decoding for the supported USSD operations
Performs the internal mapping of USSD dialog ID to TCAP dialog ID for multi
message dialogues
●
jimi - First Menu functionality
Intercepts MO PSSR requests which matches a top level menu in Transact
configuration
●
drum – Dialog Manager
Manages and resolves dialog information for USSD messages which are
transiting the core routing bus
Modifies inflight messages and embeds USSD TLVs
Enforces upper limit of maximum parallel dialogs
Ensures only one dialog is active for a given handset
USSD First Menu (jimi)
GUI Configuration – System
GUI Configuration – Dialogs
GUI Configuration – USSD Menu
 GUI Configuration – Routing Table

USSD MO Message gets routed to USSD ESME by matching MO message content

with ESME “Sing Context/Text” fields.
USSD AO Message gets routed to Mobile Network. Logic condition can be either
{IS-MT-USSD} or {IS-AO-USSD}
 GUI Configuration – ESME

USSD support mode:

– Disabled – No USSD support
– Simple – for Legacy ESMEs to do simple USSD push/pull without TLV support
– Openmind Networks Transactional Model – for USSD ESMEs with full TLV
support
– Multi-step
Incoming SMS Support:
– Should be set to No for USSD ESMEs which only send USSD messages
USSD Dialogue Scope:
– ESME/Session
Canned USSD PSSR Response:
– Used only in USSD Support mode “Simple”, this defines USSD response
content to Handset for MO Pull request
 Troubleshooting

• SS7 logging, channel 7 – Opcodes 59, 60, 61

• SMPP logging, channel 3 – check TLVs
• XENA – channel 3 (scripts/undump.pl)
• For MO routing issues verify that message content matches ESME
sink address
• Verify USSD components drum and gummi, jimi are running.
• Verify SIGTRAN associations are ACTIVE.
• Verify SMPP sessions for USSD ESMEs are bound.
Examples & Questions