Global USSD Platform - General Description

Version 1.0 Public Rel. 10 March 2011

Document History

Version Date Authors Brief description

1.0 10.03.2011 Alexey

Smelov

smelov@eyeli

ne.mobi

Initial Version

Global USSD Platform - General DescriptionIntroductionTypical CaseGeneral Scheme

Stage 1 - Service InitiationStage 2 - Service Request ProcessingStage 3 - Service CompletionSequence Diagram

VariationsService Initiation by SMSUsage of Packet Data Network

Links

Link to the original document

IntroductionGlobal USSD is a technology intended to let businesses easily

create and launch mobile services with global coverage and without the

need to get involved with mobile operators neither technically nor

contractually.

To achieve it, three basic problems were to be solved:

1. Putting through a service request to Global USSD platform made by

a mobile user in any network in any country;

2.Recognizing the request and connecting the proper service

provider;

3. Linking the user and the service provider by setting up a dialog

between the two.

Following the task formulation three basic technologies were

developed:

1.Eyeline Service Delivery Platform (ESDP) - firstly, runs the

system’s central logic; secondly, connects service providers;

2. Call-2-Service - receives and performs primary analysis of users’ requests;

3.SMS/USSD Gateway - enables communication between a user and a service provider coming after the user’s request.

In actuality, there are a lot more functions than those mentioned

above, that the system runs in the course of its operation, like user

identification and authorization, charging, logging and statistics,

operation and maintenance, personalization and advertising. These

functions are described in other documents, some of which are referred

to herein.

Typical CaseLet us take an international parcel company for a typical case of

usage of Global USSD. The company would like to give its customers a

feature of easy parcel tracking using their mobile phones. Since the

company is international, its customer base is formed of residents of

many countries, subscribers of different mobile operators.

Let us assume that the following service scenario has been devised:

1.A user sends a request to the parcel company from his mobile

phone;

2. The company’s system sends back a service menu through the USSD

channel;

3. The user chooses the menu item “Track shipment”;

4. The system asks the user to enter the tracking number;

5. The user enters the tracking number;

6.The user gets back an SMS message containing the tracking

information.

The Global USSD solution has been chosen for the reason that

establishing a USSD message channel individually with every operator

is practically impossible.

General SchemeLet us cast a broad glance at entities participating in the service

scenario described above.

Picture 1 - General scheme of mobile service based on Global USSD

The User communicates with the Service Provider through a Mobile

Network (PLMN), which can be his Home Network (HPLMN), or a Visited

Network (VPLMN).

Global USSD consists of three main parts: Call-2-Service, ESDP, and

SMS/USSD Gateway, as it was mentioned above.

The Service Provider is connected to Global USSD Platform through

Internet using a secure channel.

In terms of geography a mobile network, Global USSD, and a service

provider may be either situated close to each other (e.g. within

the same city), or separated by county or country borders, or even

oceans. That is to say, a situation is quite realistic where a user

from Sweden roaming in Brazil communicates with a service provider in

London through Global USSD platform located in Moscow.

Stage 1 - Service InitiationUsually it does not make any problem to put through a service

request when both a service provider and a user are connected to

the same mobile network, and everything is controlled by a single

mobile network operator. In our case it is a challenge since the MNO

servicing the User has no direct connection with Global USSD and the

Service Provider and even may not know of their existence. To overcome

this challenge the technology Call-2-Service is used.

To reach the service (in our case it is a parcel tracking service)

the User dials a certain phone number (let’s say +44 5600211234). The

number is dialled in the usual way, as if a voice call is attempted.

The request is routed by the mobile network, and at some point it

leaves the mobile network and through international public phone

carries reaches the destination country, enters the VoIP domain and

finally terminated at the Call-2-Service server. Since it is a regular

voice call request, the routing is done in the standard way using ISUP

and SIP protocols all the way through the PLMN and PSTN networks, and

nothing special is needed at this phase.

Call-2-Service has a Soft Switch in its core which receives the

request, extracts the caller’s MSISDN as well as the dialled phone

number. Then it transmits the extracted information to ESDP using SMPP

protocol and finally rejects the voice call by sending back SIP BYE request which will result in busy tone (or call rejected tone) in the User’s mobile handset.

Thus the system gets all the necessary information about the service

that has been requested as swell as the request initiator, and here

the first stage is over.

Stage 2 - Service Request ProcessingRule Engine is the very core of ESDP. It performs the basic system

functions, like connecting users and service providers, running

intricate service scenarios, putting together other ESDP subsystems

(Service Adaptation, Charging, Statistics, O&M etc.), so that they

work in cohesion.

In the current example Rule Engine operates with the User’s MSISDN

(Originator ID) and the phone number +44 5600211234 that the User

dialled to get the parcel tracking service (Destination ID). By

analyzing the Destination ID Rule Engine selects the proper Service Provider and sends it a service menu request. Before the request

reaches the Service Provider’s system it is passed through Service

Adaptation subsystem of ESDP.

Service Adaptation subsystem (a.k.a. Eyeline Mobilizer) is the back

end of ESDP that faces service providers. Its main task is protocols

modification and adaptation, thus shielding service providers from

the telecom specifics and giving them simple web based instruments

for fast services roll-out. To learn more about mobile services

construction using Eyeline Mobilizer see our Introductory Guide to

Creating Mobile Services with Eyeline Mobilizer.

Service Adaptation subsystem transforms the service menu request

formed by Rule Engine into an HTTP Request and forwards it to the

Service Provider. In this example the Service Provider responds with

the service menu that will look like this on the mobile phone screen:

Welcome!1>Track Shipment2>Contact Us

The response is sent back to ESDP in the form of HTTP Response

containing an XML page. The XML page contains a special tag that will

instruct ESDP that the message should be sent in a USSD form. The

number of characters the menu is composed of is essential, since the

menu is intended to reach the User as a USSD message. The maximum

number of characters in a USSD message is 180 if the standard 7-bit

ASCII character set is used, or 80 characters for UCS-2, the two-byte

Unicode. In our case the message contains only ASCII characters, so

its maximum length is 180 symbols. In fact there are only 38 symbols

that the menu consists of, including two linefeed characters. To learn

more on USSD see our USSD Basics.

Stage 3 - Service CompletionAs soon as the XML page with the menu is received by Service

Adaptation subsystem, it is converted into the ESDP internal format

and forwarded to Rule Engine for delivery. Rule Engine maintains the

session between the User and the Service Provider. The Originator ID (that is, the User’s MSISDN), which is stored as one of session parameters, is now taken as the destination address for a Network

Initiated USSD message containing the service menu. As soon as the

message is formed, it is forwarded to SMS/USSD Gateway through SMPP

protocol.

SMS/USSD Gateway is the gate to the SS7 signalling system, through

which practically all GSM/3G networks worldwide are reachable. It

gets the SMPP message from Rule Engine, converts it into a real USSD

message, and places it into SS7 as a Mobile Application Part (MAP)

message. The MAP message is delivered to the network where the User is

currently registered, that is HPLMN (the User’s home network) or VPLMN

(the network where the User roams). It is done using the standard

SS7 routing mechanism. Finally the User receives the message on his

mobile phone and sees the menu on the screen. The whole procedure

described above takes a few seconds between the moment the User dials

the service code and the moment he receives the USSD menu.

The User chooses menu item 1>Track Shipment and sends a response to the system. The modus operandi consists of selecting the “Reply” option with the mobile phone interface; typing “1” (the menu item

number); and pressing the “Send” button on the phone. It may vary

slightly depending on the phone model.

The User’s response is routed through SS7 back to SMS/USSD Gateway

where it is transformed into the SMPP format and sent to Rule Engine.

Since Rule Engine keeps track of the session, it immediately forwards

the message to Service Adaptation subsystem and then to the Service

Provider as an HTTP Request.

The Service Provider’s system automatically sends the User a new

message consisting of a single line:

Please enter tracking number

This message undergoes all the same metamorphoses in ESDP and SMS/

USSD Gateway and reaches the User. The User replies with the tracking

number, a kind of 008-2779542-413. This number goes all the way back to the Service Provider’s system where it is checked for validity

and, if the number is valid and the parcel is actually on the way,

the Service Provider’s system forms an XML page consisting of two

sections.

The first section contains the text to be sent to the User as the

closing message of the USSD dialog:

Information sent by SMS. Please wait.

This message will not require any answer from the User, it will only

inform him that the SMS message with the requested information is

oncoming.

The second section of the XML page (the two sections are separated

by a special divider tag) contains the text to be sent in an SMS

message directly following the USSD message.

Tracking number 008-2779542-413, parcel left main terminal in London 19.01.2011 at 08:45 PM, local time

There is metadata in the XML file that prescribes the carrier for the

second part of the page to be SMS.

The two-section XML file is transmitted to ESDP where it is

interpreted by Service Adaptation subsystem and divided by Rule Engine

into two separate messages (one for USSD and one for SMS). Rule Engine

further dispatches them to SMS/USSD Gateway for delivery. SMS/USSD

Gateway sends the messages one by one, first the USSD message, then

the SMS message. As soon as the SMS message is sent to the User, the

service is considered provided, and the session closes.

Sequence Diagram

The sequence diagram below illustrates the foregoing description.

Picture 2 - Typical case, the sequence diagram

VariationsDescribed above is the service scenario that we took as the default.

In fact there is variety of alternative ways for service providers to

communicate with users and a number of other mobile technologies that

can be employed. Let us consider some if them.

Service Initiation by SMSIn the foregoing scenario the service is triggered by a voice call

attempt which does not lead to a voice conversation. Another method of

service initiation is sending an SMS message to a predefined number.

Of course, this number should be a full-format international E.164

telephone code (like +7 913 911 XX XX), otherwise the SMS message

would not reach the destination. The message can be sent either empty

or containing text addressed to a service provider.

Reverting to our example, the service scenario can be devised so

that if the User sent an empty SMS message, the Service Provider

would send back the aforementioned USSD menu with two options - Track Shipment and Contact Us, and the rest of the algorithm would remain the same. However, if the SMS message contains the text “track 008-2779542-413”, the Service Provider’s system interprets it as a direct command and sends back an SMS message with the result, completely

omitting the USSD dialog stage.

With service initiation by SMS the general scheme will look a bit

different because Call-2-Service is omitted from the chain in this

case (see the picture below).

Picture 3 - General scheme of mobile service, initiation by SMS

The drawback of this method lies in the fact that sending SMS

message is not free for a user. The cost of a mobile originated SM is

all the more significant when a user is roaming abroad. The default

case with Call-2-Service is free for a user, no matter the home or a

visited network he is registered with.

Usage of Packet Data NetworkUSSD is a very fast and reliable medium of communication between a

user ans a service provider. However, with fast development of mobile

packet data networks, Mobile Internet becomes an alternative to USSD.

Let us examine the case where our illustrative service is provided

using GPRS, EDGE or UMTS packet data environment.

Let us take the initiation of the service from the default scenario,

that is by placing a voice call. Responding to the service menu

request the Service Provider’s system sets a tag in the XML page

instructing ESDP to establish a dialog with the User through HTTP

instead of USSD. Following this instruction Rule Engine forms an SMS

message containing a session specific URL and sends it to the User.

The User clicks on the link in the SMS message, the mobile web browser

opens, an HTTP connection is established between the User and the

Service Provider through a GGSN located in either a home or a visited

mobile network. In that way the User gets the Track Shipment and

Contact Us menu in the mobile web browser window instead of a USSD dialog box. The rest of the dialog and the final message informing of

the shipment status is exchanged through HTTP. As you can see in the

picture below, this service scenario does not involve USSD at all.

Picture 4 - General scheme of mobile service, usage of GPRS

The main advantage of this method is freedom from the strict USSD

restraints, like the maximum number of characters, absence of any text

formatting and non-text elements. In other words, the menu looks much

nicer and has more features.

A disadvantage will become apparent however, should a user travel

abroad. It is well known that inter-operator data tariffs are so huge,

that they make usage of data in roaming virtually impossible.

ESDP allows for automatic selection of USSD or HTTP scenario

depending on the user’s whereabouts. After receiving the service menu

request ESDP checks if the User is in the home or a foreign network.

The check is made by interchanging some MAP messages between SMS/USSD

Gateway and the user’s HLR (Home Location Registry). If the User is in

the home network, the HTTP scenario will be selected. However, if the

User is registered with a foreign network, the USSD scenario will be

selected instead. This functionality is realized in Rule Engine.

LinksSoft Switch

SIP - Session Initiation Protocol

MSISDN - Mobile Subscriber ISDN Number

ESDP

ASCII - American Standard Code for Information Interchange

UCS-2 Unicode

SMPP 3.4 Specification

XML - Extensible Markup Language

SS7 - Signalling System No 7

MAP - Mobile Application Part

E.164 - ITU-T Recommendation

GPRS - General Public Radio Service

EDGE - Enhanced Data Rates for GSM Evolution

UMTS - Universal Mobile Telecommunications System

GGSN - Gateway GPRS Support Node