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