USSD Services For Interactive Mobile Users.. 11038 An

User Manual: 11038

Open the PDF directly: View PDF .
Page Count: 17

USSD Services for

Interactive Mobile Users

Building User-Friendly Mobile

Telephony Applications Using

Dialogic® Distributed Signaling

Interface Components

Small Logo

Medium Logo

Large Logo

Application Note

Executive Summary

The application note describes the implementation of an interactive Unstructured Supplementary Service Data

(USSD) service for GSM mobile users. Information is provided to describe how service providers who decide to use

the power of USSD to provide mobile users with menu-driven, interactive services such as mobile account balance

checking and top up, sports scores, and news and weather information can do so via current technologies and

signaling.

An overview of the network architecture and a description of interactive USSD services are presented, as well as

signaling requirements for such services. Sample code also shows an application that can be developed using the

Dialogic® Distributed Signaling Interface (DSI) MAP Layer.

Finally, system design considerations are discussed, showing how high-performance USSD application platforms

can be developed with Dialogic® DSI Components, enabling system designers to offer interactive USSD services

worldwide.

Application Note

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Table of Contents

Introduction ............................................................. 2

Network Architecture for USSD Signaling ....................................... 2

USSD Signaling Requirements ............................................... 3

Example Menu-Driven USSD Application ................................... 3

How to Format USSD Text .................................................. 5

Formatting a USSD Menu .............................................. 5

Creating USSD Applications ................................................. 6

MAP Services for USSD................................................ 6

MAP Parameters for USSD ............................................. 7

Information for System Design: Working with MAP USSD Signaling .................... 8

Code Modiﬁcations to the Dialogic® “MTU” Example Application ................. 8

Dialogic® DSI Components for USSD Services ................................... 11

Summary .............................................................. 13

References ............................................................ 13

Acronyms ............................................................. 14

For More Information ..................................................... 14

Application Note

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Introduction

Unstructured Supplementary Service Data (USSD) is a

capability built into GSM phones, much like the Short Message

Service (SMS).

USSD differs from SMS as follows:

SMS uses a “store and forward” technique to deliver text •

messages:

A text message is ﬁrst sent to a sender’s Short Message

Service Center (SMSC) before the SMSC tries to deliver

the text message to the recipient. The sender receives an

indication of whether the text was successfully received by

the SMSC; however, the text message is not guaranteed to

reach the recipient instantly.

Note: The “SMS Router” concept can be used to improve

SMS delivery time in some instances.

USSD information is sent directly from a sender’s mobile •

handset to an application platform handling the USSD

service. The USSD service can be located either in the

sender’s mobile network or in a visited mobile network.

A real-time “session” is initiated between the mobile user •

and the USSD application platform when the service is

invoked, allowing data to be sent back and forth between

the mobile user and the USSD application platform until

the USSD service is completed.

This concept of a real-time data session is particularly useful if

opting to build an interactive menu-driven application, such as

a mobile-initiated “Balance Enquiry and Top Up” application,

as described in the Example Menu-Driven USSD Application

section.

Note: A USSD service could be invoked by either the mobile

user or the USSD platform [GSM TS 23.090 Unstructured

Supplementary Service Data (USSD) - Stage 2].

Network Architecture for USSD Signaling

USSD services use the existing architecture of GSM networks. A

user dialing a USSD service code initiates a dialog with a USSD

application residing in a mobile network, as detailed in Figure

1. The “Network Node,” shown in Figure 1, could be either an

MSC, VLR, HLR, or other network entity, such as an application

platform, which has access to the speciﬁc USSD service.

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

MMI

Mobile User

USSD Handler

Mobile Station

Application

USSD Handler

Network Node

Source: European Telecommunications Standards Institute (ETSI)

[TS 23.090]: “The Unstructured Supplementary Service Data (USSD) mechanism allows

the Mobile Station (MS) user and a PLMN operator-deﬁned application to communicate

in a way which is transparent to the MS and to intermediate network entities.”

Figure 1. Handling of USSD

3GPP TS 22.090 details speciﬁc “MMI strings” or telephone

numbers that could be dialed from a user’s “mobile station”

(mobile handset) to initiate USSD services. Speciﬁcally, the

following number range is deﬁned as being allocated in GSM

networks for USSD services residing in the user’s Home Public

Land Mobile Network (HPLMN):

[3GPP TS 22.090]:

“1, 2 or 3 digits from the set (*, #) followed by 1X(Y), where

X=any number 0-4, Y=any number 0-9, then, optionally “*

followed by any number of any characters”, and concluding

with # SEND”.

For example, a user could dial *#123# from the user’s mobile

handset to reach a speciﬁc USSD service, where the USSD

application itself resides in the user’s HPLMN.

In this way, the application developer could decide to build,

install, and advertise use of a USSD service such as a menu-

driven application (see the Example Menu-Drive USSD

Application section) within a particular mobile network. The

new USSD service would be available worldwide to subscribers

to that mobile service via the USSD service number, which

follows the rules detailed in 3GPP TS 22.090.

USSD Signaling Requirements

Example Menu-Driven USSD Application

One could decide to develop a mobile-initiated “Balance

Enquiry and Top Up” application using USSD signaling,

enabling a mobile user to interact with an application via the

user’s handset, in order to view his/her current mobile account

balance and top up as needed.

An example of such an application could be as follows:

1. A mobile user initiates the “Balance Enquiry and Top Up”

service by dialing the USSD string deﬁned by the service

provider; for example, *#123#.

Note: See [3GPP TS 22.090] for more details regarding

USSD string formats.

2. The USSD application receives the service request from the

user and responds by sending the user a menu of options.

3. The user responds by selecting a “current balance” option.

4. The USSD application sends back details of the mobile

user’s current account balance and also gives the option

to top up the balance.

5. The user selects to top up his/her account.

6. The application responds by asking how much credit to

add?

7. The mobile user responds with the amount to add.

8. The USSD application responds by sending an updated

balance and ends the session.

Figure 2 shows an example of the MAP/TCAP message

sequence required to realize the data transfers between a

mobile user’s handset and the USSD application to implement

the “Balance Enquiry and Top Up” service described above.

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

Figure 2. Mobile-Initiated “Balance Enquiry and Top Up” Service (adapted from Figure 6.2, [3GPP TS 24.090])

Notes on the USSD MAP/TCAP numbered message sequence shown in Figure 2:

1. The mobile-initiated USSD service commences with a mobile user dialing the USSD string (for example, *#123#). A TCAP

dialogue is initiated following this, with a MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service component sent to the

USSD application platform.

2. The USSD application platform receives the request to initiate a USSD service from the mobile user. The platform determines

the speciﬁc USSD service requested by checking the USSD string dialed.

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

USSD Application

Platform

Mobile

Handset

1. User dials

*#123#<SEND> TCAP Begin

invoke

MAP_PROCESS_UNSTRUCTURED_SS_REQUEST

TCAP Continue

invoke

MAP_UNSTRUCTURED_SS_REQUEST

Welcome to XYZ Telecom

Press:

(1) Balance Notification

(2) Top Up service

3. User presses 1<SEND>

TCAP Continue

return result (last)

MAP_UNSTRUCTURED_SS_REQUEST

TCAP Continue

invoke

MAP_UNSTRUCTURED_SS_REQUEST

Your current balance is: 5.50

Press:

(1) to Top Up

(2) to end

5. User presses 1<SEND>

TCAP Continue

return result (last)

MAP_UNSTRUCTURED_SS_REQUEST

TCAP Continue

invoke

MAP_UNSTRUCTURED_SS_REQUEST

XYZ Telecom Top Up

Please enter:

The amount to Top Up

e.g. 10.00

7. User presses 15.00<SEND>

TCAP Continue

return result (last)

MAP_UNSTRUCTURED_SS_REQUEST

TCAP End

return result (last)

MAP_PROCESS_UNSTRUCTURED_SS_REQUEST

Thank you for using XYZ

Top Up! Your current

balance is: 20.50

The USSD platform requests additional information from the mobile user (balance notiﬁcation or top up?) via the MAP_

UNSTRUCTURED_SS_REQUEST service.

3. The USSD platform receives the user’s response within a MAP_UNSTRUCTURED_SS_REQUEST return result component.

4-7. The USSD application could request additional information from the mobile user several times for the same TCAP dialogue,

each time the MAP_UNSTRUCTURED_SS_REQUEST service would be used, as shown in sequence 4 through 7.

8. Finally, the network USSD application platform ends the TCAP dialogue, sending MAP_PROCESS_UNSTRUCTURED_SS_

REQUEST return result (Thank you for using XYZ…).

In the above example, the USSD platform requests further information from the mobile user via the MAP_UNSTRUCTURED_SS_

REQUEST service. If the USSD platform did not require any further information from the mobile user, the USSD application could

respond by sending a MAP_PROCESS_UNSTRUCTURED_SS_REQUEST return result component (as shown in Figure 2, point

8) and ending the TCAP dialogue.

For more information on mobile- (and network-) initiated USSD operations and the use of MAP USSD services, refer to [3GPP

TS 24.090] in the References section.

How to Format USSD Text

In the “Balance and Top Up” service example shown in Figure 2, the network USSD application responds to inputs from the

mobile user with various menus and questions. Figure 3 shows an example of a menu on a mobile handset.

Figure 3. USSD Menu Example on a Mobile Handset

Formatting a USSD Menu

How Is Menu Information Sent to the User?

The menu, as it appears on the screen of the mobile handset, is actually a straightforward text string broken up using carriage

return <CR> characters as shown in Figure 4.

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

Welcome to XYZ Telecom

Press:

1. Balance Notification

2. Top Up Service

Figure 4. Formatting a USSD Menu for Display on a Handset

Creating USSD Applications

MAP Services for USSD

As shown in Figure 2, MAP services “MAP_UNSTRUCTURED_SS_REQUEST” and “MAP_PROCESS_UNSTRUCTURED_SS_

REQUEST” are used to deliver text that forms the menus, questions, and answers between a network USSD application platform

and a mobile user’s handset.

Note: MAP services PROCESS_UNSTRUCTURED_SS_REQUEST and UNSTRUCTURED_SS_REQUEST are deﬁned in [3GPP TS

29.002].

These two MAP services both use parameters “USSD Data Coding Scheme” and “USSD String” as detailed in Figure 5.

Figure 5. USSD MAP Service Deﬁnitions from [MAP Programmer’s Manual]

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

Welcome to XYZ Telecom

Press:

1. Balance Notification

2. Top Up Service

The text string:

Welcome to XYZ Telecom<CR>Press:<CR>1. Balance Notication <CR>2. Top Up Service

Will be presented on the handset as ...

UNSTRUCTURED_SS_REQUEST

Parameter Class Context

Primitive type octet M V1, V2

Timeout (default = 600 seconds) O V1, V2

Invoke ID M V1, V2

USSD Data Coding Scheme M V1, V2

USSD String M V1, V2

Alerting pattern O V2

MSISDN O V2

PROCESS_UNSTRUCTURED_SS_REQUEST

Parameter Class Context

Primitive type octet M V1, V2

Timeout (default = 600 seconds) O V1, V2

Invoke ID M V1, V2

USSD Data Coding Scheme M V1, V2

USSD String M V1, V2

Alerting pattern O V2

MSISDN O V2

Ellipsis O V2

MAP Parameters for USSD

USSD Data Coding Scheme

As deﬁned in 3GPP TS 29.002, this parameter details “the alphabet and the language used for the unstructured information in

an Unstructured Supplementary Service Data operation.”

Encoding is according to 3GPP TS 23.038 section “Cell Broadcast Data Coding Scheme”. A typical encoding scheme used is as

follows:

“GSM 7 bit default alphabet”, encoded within the parameter as “00001111”.

The following code sample shows how the “GSM 7 bit default alphabet” USSD Data Coding scheme parameter could be encoded

within a customer application:

For more information, see [3GPP TS 23.038] listed in the References section.

USSD String

USSD characters are packaged using a 7 bit encoding scheme, much like SMS characters, as deﬁned in 3GPP TS 23.038.

The Dialogic® source code sample software, “MAP Test Utility”, contains a function example called “MTU_str_to_def_alph()”.

The function MTU_str_to_def_alph() converts an ascii string into “GSM 7 bit default alphabet” encoding, following rules deﬁned

in [3GPP TS 23.038] (also see Note: Support for USSD Character Packing below). This function can be useful, such as if creating

a USSD string text to send over a GSM network based upon user input.

To test usage of the MTU_str_to_def_alph() function, the following code sample (based upon MTU source code) encodes a USSD

string menu text similar to that which was previously discussed:

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

/* USSD coding parameter */

bit _ set(req.pi, MAPPN _ USSD _ coding);

* USSD coding set to ‘GSM default alphabet’ 00001111

* see 3GPP TS 23.038 ‘Cell Broadcast Data Coding Scheme’

* for further detail

bit _ to _ byte(req.ussd _ coding.data, 0x1, 0);

bit _ to _ byte(req.ussd _ coding.data, 0x1, 1);

bit _ to _ byte(req.ussd _ coding.data, 0x1, 2);

bit _ to _ byte(req.ussd _ coding.data, 0x1, 3);

bit _ to _ byte(req.ussd _ coding.data, 0x0, 4);

bit _ to _ byte(req.ussd _ coding.data, 0x0, 5);

bit _ to _ byte(req.ussd _ coding.data, 0x0, 6);

bit _ to _ byte(req.ussd _ coding.data, 0x0, 7);

req.ussd _ coding.num _ bytes = 1;

Note the use of “\n” to encode a carriage return, as required for menu type text displays.

Note: Support for USSD Character Packing — 3GPP TS 23.038 (deﬁned in the “USSD packing” section) details two USSD text

cases that the supplied example function MTU_str_to_def_alph() does not support. In the two cases, the user could extend the

MTU_str_to_def_alph() function source code as follows:

1. “If the total number of characters to be sent equals (8n-1), where n=1,2,3, etc., then there are 7 spare bits at the end of the

message. To avoid the situation where the receiving entity confuses 7 binary zero pad bits as the @ character, the carriage

return or <CR> character … shall be used for padding in this situation, just as for Cell Broadcast.”

2. “If <CR> is intended to be the last character and the message (including the wanted <CR>) ends on an octet boundary, then

another <CR> must be added together with a padding bit 0.”

See [3GPP TS 23.038] for more information on these two cases, in order to develop a complete str_to_def_alph() function.

Information for System Design: Working with MAP USSD Signaling

Code Modiﬁcations to the Dialogic® “MTU” Example Application

The following section has an example of a function that can be used to send the service MAP_PROCESS_UNSTRUCTURED_SS_

REQUEST to initiate a USSD session, as previously shown in Figure 2.

The code is based upon the structure of existing code for other MAP services supplied for the MAP Test Utility (MTU) example,

as part of the Dialogic® User Part Development package [MTU and MTR User Guide].

This code sample indicates how to set the MAP service name for MAP_PROCESS_UNSTRUCTURED_SS_REQUEST and includes

the USSD speciﬁc parameters “USSD Data Coding Scheme” and “USSD String” previously described.

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

/* USSD string parameter */

bit _ set(req.pi, MAPPN _ USSD _ string);

* USSD string

mtu _ args.message=

“Welcome to XYZ Telecom\n Press:\n 1. Balance Notication\n 2. Top Up Service”;

num _ da _ chars = MTU _ str _ to _ def _ alph(mtu _ args.message,

&req.ussd _ string.data[req.ussd _ string.num _ bytes],

&da_len,

MAX _ DATA _ LEN - req.ussd _ string.num _ bytes);

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

Code Sample to Send

MAP_PROCESS_UNSTRUCTURED_SS_REQUEST

static int MTU _ process _ uss _ req (dlg _ id, invoke _ id) /* USSD */

u16 dlg _ id; /* dialogue ID */

u8 invoke _ id; /* invoke ID */

{

MTU _ DLG *dlg; /* dialogue data structure */

MTU _ MSG req; /* structured form of request message */

u8 da _ len; /* length of formatted u-data */

u8 num _ da _ chars; /* number of formatted*/

dlg = &(dlg _ data[dlg _ id]);

* The following parameters are set in the

* MAP _ PROCESS _ UNSTRUCTURED _ SS _ REQUEST:

* ussd-DataCodingScheme

* ussd-string - this will be entered by the user e.g. *#123#

memset((void *)req.pi, 0, PI _ BYTES);

req.dlg _ id = dlg _ id;

req.type = MAPST _ PRO _ UNSTR _ SS _ REQ _ REQ;

req.invoke _ id = invoke _ id;

bit _ set(req.pi, MAPPN _ invoke _ id);

/* USSD coding parameter */

bit _ set(req.pi, MAPPN _ USSD _ coding);

* USSD coding set to ‘GSM default alphabet’ 00001111

* see 3GPP TS 23.038 ‘Cell Broadcast Data Coding Scheme’

* for further detail

bit _ to _ byte(req.ussd _ coding.data, 0x1, 0);

bit _ to _ byte(req.ussd _ coding.data, 0x1, 1);

bit _ to _ byte(req.ussd _ coding.data, 0x1, 2);

bit _ to _ byte(req.ussd _ coding.data, 0x1, 3);

bit _ to _ byte(req.ussd _ coding.data, 0x0, 4);

bit _ to _ byte(req.ussd _ coding.data, 0x0, 5);

bit _ to _ byte(req.ussd _ coding.data, 0x0, 6);

bit _ to _ byte(req.ussd _ coding.data, 0x0, 7);

req.ussd _ coding.num _ bytes = 1;

/* USSD string parameter */

bit _ set(req.pi, MAPPN _ USSD _ string);

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

* USSD string

req.ussd _ string.num _ bytes = 1; /* USSD string, allow byte for data length */

num _ da _ chars = MTU _ USSD _ str _ to _ def _ alph(mtu _ args.ussd _ string,

&req.ussd _ string.data[req.ussd _ string.num _ bytes],

&da_len,

MAX _ DATA _ LEN - req.ussd _ string.num _ bytes);

* ll in the ussd _ string, the number of formated default alphabet

characters

req.ussd _ string.data[req.ussd _ string.num _ bytes - 1] = num _ da _ chars;

req.ussd _ string.num _ bytes += da _ len;

* Operation timeout - 15 seconds

bit _ set(req.pi, MAPPN _ timeout);

req.timeout = 15;

MTU _ send _ srv _ req(&req);

return(0);

} /* end of MTU _ process _ uss _ req() */

Encoding Application Context for USSD Version 2 Operations

The following code sample can be used to add support within MTU for the USSD version 2 application context, as deﬁned in

[3GPP TS 29.002].

Add the following deﬁnition to mtu.c:

/* new application context networkUnstructuredSsContext-v2 */

static u8 networkUnstructuredSsContextV2[AC _ LEN] =

{

06, /* object identier */

07, /* length */

04, /* CCITT */

00, /* ETSI */

00, /* Mobile domain */

01, /* GSM network */

00, /* application contexts */

19, /* map-ac networkUnstructuredSs */

02 /* version 2 */

};

Add the following code to mtu.c function “MTU_open_dlg” to make use of the USSD version 2 application context:

Dialogic® DSI Components for USSD Services

Dialogic® DSI SS7 Boards, Dialogic® DSI Protocol Stacks, and Dialogic® DSI Signaling Servers can be used to create the network

elements required to develop a USSD service such as the mobile “Balance Enquiry and Top Up” application described in this

application note.

As an example, Figure 6 shows a Dialogic® DSI-based USSD platform developed using high-density PCIe signaling cards. The

USSD platform uses a pair of servers and signaling cards that act as a single SS7 end point, providing availability and a high

degree of fault tolerance.

Depending on the amount of USSD signaling trafﬁc anticipated, multiple TDM Low Speed Links (LSL) (64 kbps) could be

deployed. For systems with larger throughput requirements, TDM High Speed Links (HSL) could be deployed, with each signaling

link giving approximately 2 Mbps of signaling throughput.

Figure 6. Implementing a USSD Application Platform with Dialogic® DSI Components — TDM SS7 Connections Example

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

case MTU _ PROCESS _ USS _ REQ:

* Send MAP _ PROCESS _ UNSTRUCTURED _ SS _ REQUEST

for (i=0; i<AC _ LEN; i++)

req.applic _ context[i] = networkUnstructuredSsContextV2[i];

break;

MSC/VLR

MSC/VLRMSC/VLR

BSS

Prepaid

mobile user

Prepaid

mobile user

Dialogic® based USSD Platform mobile

“Balance Enquiry and Top Up” application

HLR

TDM SS7 (Possibly HSL)

Alternatively, the Dialogic® DSI SIGTRAN Stack could be used to connect the USSD application platform to the mobile network.

Figure 7 shows a similar example deployed using Dialogic® DSI SUA Layer, where the example includes two application server

processes for resilience. For SIGTRAN deployments, throughput is not limited by signaling link bandwidth as in the TDM world;

instead, high-speed Ethernet provides bandwidth for high-performance MAP USSD applications.

Figure 7. Implementing a USSD Application Platform with Dialogic® DSI Components — DSI SIGTRAN Stack Connections Example

As examples, Dialogic® DSI Protocol Stacks could be used to develop systems over:

SS7 TDM using Dialogic• ® DSI SS7 Stack - DSI MAP Layer, DSI TCAP Layer, and DSI SCCP Layer

SIGTRAN using Dialogic• ® DSI SIGTRAN Stack - DSI SUA Layer, DSI M3UA Layer, or DSI M2PA Layer

For GSM MAP signaling, a number of Dialogic® DSI Components are available including:

Dialogic• ® DSI SS7AM1 Network Interface Boards (Advanced Mezzanine Card for AdvancedTCA)

Dialogic• ® DSI Signaling Servers

Dialogic• ® DSI SS7HDE Network Interface Boards (PCIe SS7 board)

Dialogic• ® DSI SS7HDC Network Interface Boards (cPCI SS7 boards)

Dialogic• ® DSI SS7HDP Network Interface Boards, Dialogic® SPCI4 Network Interface Boards (PCI SS7 Boards)

A choice of products is available based upon factors such as the level of integration needed, expected transaction rate, and the

level of fault tolerance required. The same Application Programming Interface (API) is used across the Dialogic® DSI Component

family, allowing easy migration from board-based to server-based solutions, or from TDM to IP (SIGTRAN) as service needs

change. For more information on the range of Dialogic® DSI Components available, see the For More Information section.

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

MSC/VLR

MSC/VLRMSC/VLR

BSS

Prepaid

mobile user

Prepaid

mobile user

Dialogic® based USSD Platform mobile

“Balance Enquiry and Top Up” application

HLR

Dialogic® DSI SUA Layer

Summary

This application note described interactive USSD services for GSM mobile users and showed how such a service could be

provided using GSM MAP signaling.

An example mobile-initiated “Balance Enquiry and Top Up” application was described, detailing the MAP services and parameters

required by a network-based USSD application, and showed how USSD text strings are handled by the application for sending to

mobile users’ handsets.

Finally, system designs were considered, providing USSD service designers with the option to develop and deploy USSD

applications with Dialogic® DSI Boards, Dialogic® DSI Servers, and Dialogic® DSI Protocol Stacks.

References

[3GPP TS 22.090] Digital cellular telecommunications system (Phase 2+);

Universal Mobile Telecommunications System (UMTS); Unstructured Supplementary Service Data (USSD); Stage 1

[3GPP TS 23.038] Digital cellular telecommunications system (Phase 2+);

Universal Mobile Telecommunications System (UMTS); Alphabets and language-speciﬁc information

[3GPP TS 23.090] Digital cellular telecommunications system (Phase 2+);

Universal Mobile Telecommunications System (UMTS); Unstructured Supplementary Service Data (USSD); Stage 2

[3GPP TS 24.090] Digital cellular telecommunications system (Phase 2+);

Universal Mobile Telecommunications System (UMTS); Unstructured Supplementary Service Data (USSD); Stage 3

[3GPP TS 29.002] Digital cellular telecommunications system (Phase 2+);

Universal Mobile Telecommunications System (UMTS); Mobile Application Part (MAP) speciﬁcation

[MAP Programmer’s Manual] Dialogic® SS7 Protocols MAP Programmer’s Manual

http://www.dialogic.com/support/helpweb/signaling/software3.htm

[MTU and MTR User Guide] Dialogic® SS7 Protocols MAP Test Utility (MTU) and Responder (MTR) User Guide

http://www.dialogic.com/support/helpweb/signaling/software3.htm

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

Acronyms

3GPP 3rd Generation Partnership Project

API Application Programming Interface

HLR Home Location Register

HPLMN Home Public Land Mobile Network

MAP Mobile Application Part

MSC Mobile Switching Center

MSISDN Mobile Subscriber ISDN Number

MTU MAP Test Utility

SCCP Signaling Connection Control Part

SMS Short Message Service

TCAP Transaction Capabilities Application Part

USSD Unstructured Supplementary Service Data

VMSC Visited MSC

For More Information

3GPP / ETSI publications — http://webapp.etsi.org/key/queryform.asp

Dialogic® DSI Components Information — http://www.dialogic.com

Dialogic® DSI Software and Documentation — http://www.dialogic.com/support/helpweb/signaling/

USSD Services for Interactive Mobile Users

Building User-Friendly Mobile Telephony Applications Using

Dialogic® Distributed Signaling Interface Components

Application Note

www.dialogic.com

Dialogic Corporation

9800 Cavendish Blvd., 5th oor

Montreal, Quebec

CANADA H4M 2V9

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH PRODUCTS OF DIALOGIC CORPORATION OR ITS SUBSIDIARIES (“DIALOGIC”). NO LICENSE, EXPRESS

OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN A SIGNED AGREEMENT

BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/

OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY

INTELLECTUAL PROPERTY RIGHT OF A THIRD PARTY.

Dialogic products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications.

Dialogic may make changes to specications, product descriptions, and plans at any time, without notice.

Dialogic is a registered trademark of Dialogic Corporation. Dialogic’s trademarks may be used publicly only with permission from Dialogic. Such permission may only be

granted by Dialogic’s legal department at 9800 Cavendish Blvd., 5th Floor, Montreal, Quebec, Canada H4M 2V9. Any authorized use of Dialogic’s trademarks will be subject

to full respect of the trademark guidelines published by Dialogic from time to time and any use of Dialogic’s trademarks requires proper acknowledgement.

The names of actual companies and products mentioned herein are the trademarks of their respective owners. Dialogic encourages all users of its products to procure all

necessary intellectual property licenses required to implement their concepts or applications, which licenses may vary from country to country.

Any use case(s) shown and/or described herein represent one or more examples of the various ways, scenarios or environments in which Dialogic products can be used.

Such use case(s) are non-limiting and do not represent recommendations of Dialogic as to whether or how to use Dialogic products.

therefore provided to you “as is” for information purposes only. Further use is strictly prohibited.

Small Logo

Medium Logo

Large Logo

USSD Services For Interactive Mobile Users.. 11038 An

Navigation menu

Versions of this User Manual:

Views

Navigation